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ABSTRACT 


With  the  introduction  of  formal  specification  of 
abstracted  computer  resources,  both  physical  and  logical, 
there  is  the  possibility  that  a  major  step  forward  can  be 
made  toward  developing  a  methodology  for  reducing  the 
portability  and  reusability  costs  of  computing  system 
components.  Still,  the  current  methodology  is  only  concerned 
with  the  static  functional  properties  of  resources  and  not 
their  timing  properties.  This  places  limitations  on  the 
generality  of  the  method.  This  study  describes  a  way  to 
formally  specify  the  timing  of  computer  systems  by  combining 
ideas  of  both  semantic  algebras  and  Petri  Nets. 
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I.   INTRODUCTION 

Timing  in  computer  systems  has  been  a  critical  issue 
throughout  the  evolution  of  computers.  The  most  obvious  areas 
where  timing  is  of  great  concern  are  operating  systems, 
distributed  systems  and  real-time  systems.  In  the  most  other 
areas,  timing  of  a  computer  program  is  taken  for  granted 
since  we  assume  a  simple  sequential  execution  of  this 
program.  But  we  have  to  realize  that,  when  we  consider  the 
program  and  the  machine  on  which  it  has  to  run  as  a  whole, 
i.e.  a  computer  system,  we  have  to  deal  also  with  the 
internal  timing  of  the  hardware.  Even  though  high  level 
programming  languages  have  provided  us  with  the  means  to 
software  from  one  system  to  another,  we  still  find  these 
programs  may  not  work  properly  because  of  timing  problems. 
These  timing  problems  are  normally  caused  by  different 
implementations  of  computer  resources.  So  It  would  be  very 
helpful  to  have  a  way  of  comparing  computer  systems  and 
predicting  problems  in  timing  when  programs  are  transferred. 
It  would  even  be  much  better  to  have  specifications  of 
computer  systems  that  could  be  used  to  design  transf errab 1 e 
programs  in  the  first  place. 

There  is  ongoing  research  at  the  Naval  Postgraduate 
School  on  the  formal  specifications  of  computer  systems  that 
is   mainly   intended   to   overcome   the   increasing   costs  of 


computer  software  resulting  from  problems  with  portability 
and  reusability  of  programs.  The  first  result  of  this 
research  project  has  been  the  development  of  a  formal 
specification  methodology  by  Davis  (1984).  This  methodology 
was  successfully  used  to  write  a  formal  specification  of  an 
Abstract  Processor  by  Yurchak  (1984). «  This  work  was  followed 
by  several  extensions  of  the  Abstract  Processor  and  related 
work  by  Hunter  (1985)  and  Zang  (1985).  The  research  performed 
at  the  Naval  Postgraduate  School  is  part  of  a  relatively  new 
branch  of  computer  science:  the  Science  of  Computing  System 
Design  which  is  concerned  with  a  formal  approach  to  the 
specification  and  description  of  computer  systems.  This 
thesis  follows  the  direction  of  previous  work  done  in  this 
field.  Its  objective  is  to  formally  specify  timing  in 
computer  systems.  Even  though  there  has  been  considerable 
interest  in  timing,  our  approach  will  emphasize  two  aspects 
of  the  problem: 

-  We  want  to  develop  a  formal  way  to  specify  timing  to 
achieve  the  benefits  of  the  rigorous  foundation  of  a 
formal  description. 

-  We  want  to  specify  abstracted  resources  which  include 
both  hardware  and  software  with  a  unified  approach. 

Throughout  this   thesis  the   term  "computer  resources"  is 

used  in  a   sense   that   combines   all   hardware   and  software 

building  blocks   of  computer  systems:  memory,  registers,  data 

types,  instructions,  etc..  Also   the   special   aspect   we  are 


'An  edited   version  of  the  specification  of  the  Abstract 
Processor  is  included  in  Appendix  A 
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concerned  with  is  time  as  a  computer  resource.  Computer 
resources  can  be  either  pure  physical  or  they  can  be  an 
abstract  type.  A  memory  cell  belongs  to  the  physical  category 
while  a  specific  data  type  belongs  to  the  abstract  category. 
The  means  to  deal  with  these  differences  is  abstraction. 
Specifying  computer  resources  as  abstractions  in  a 
mathematical  way  also  allows  us  to  compare  different 
specifications  and  implementations. 

Within  this  work  we  will  emphasize  a  practical  viewpoint. 
Even  though  in  applying  pure  mathematical  concepts  to 
computer  systems  we  realize  that  computers  are  in  no  way 
ideal:  as  every  piece  of  hardware  is  finite  (especially  the 
memory)  and  an  event  in  the  computer  is  never  instantaneous 
but  will  take  a  certain  amount  of  time.  In  this  context,  for 
example,  the  term  "digital  computer"  is  misleading  since 
there  are  many  undefined  states  between  those  defined  n0M  and 
"i". 

Therefore   the   goal   of   this   thesis   is   to   provide  a 
methodology  for  the  rigorous  specification  of  timing: 

-  to  evaluate  the  time  behavior  of   systems  which   leads  to 
the  exhibition  of  possible  places  in  system  where 
parallelism  could  be  used, 

-  to  give  a  better  understanding  of  the  dynamic  aspect 
of  computer  resources  in  time,  and 

-  to  find  time  critical  situations  in  a  system. 
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I  I.  BACKGROUND 

A.   FORMAL  SPECIFICATION 

The  idea  of  specifying  a  system  formally  is  to  deal  with 
physical  and  abstract  computer  resources  as  abstractions  to 
support  our  major  concerns  with  portability  and  reusability. 
In  this  sense  we  deal  with  computer  resources  as  abstractions 
which  we  want  to  describe  such  that  the  functions  and  the 
properties  of  a  resource  are  stated  in  a  mathematical  way  to 
support  precision  and  provability.  Studies  in  this  direction 
have  been  conducted  by  many  researchers  (Goguen  (1978), 
Guttag  (1978),  Bergstra  (1983),  and  Davis  (1984)).  As  a  short 
introduction  to  this  work  we  would  like  to  present  some  key 
issues  here  as  they  were  used  in  the  first  formal 
specification  of  the  Abstract  Processor. 

The  formal  specification  of  the  Abstract  Processor  is 
based  on  the  method  of  algebraic  specification  which  consists 
of  two  parts:  the  interface  specification  and  the  constraints 
specification.  The  interface  specification  declares  operands 
and  the  operators  that  can  be  applied  to  them,  so  information 
for  syntactic  constructions  and  type  checking  are  provided. 
The  constraints  specification  is  a  set  of  properties  that 
define  constraints  on  the  operations.  These  properties  are 
stated  by  equations  that  associate  the  same  meaning  to  pairs 
of   expressions   of   the   specification.   As   an   example  the 
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specification  of   the  computer  resource  "boolean"  is  shown  in 
Figure  2. 1. 

Resource  boolean   is 

Operands 

boo  I 

Operators 

not:    boo  J    ->   bool ; 
and:    bool , bool    ->   bool; 
true:    ->    bool; 
false:    ->   bool; 

Properties 

not  ( true ( )  )    =   falseO; 
not (not (x J )    -    x; 

and ( true ( )  ,  x )    =    x; 

and( fal se( ) ,  x)    -    falseO; 

end   boolean; 

Figure  2.1:  Specification  for  Resource  "boolean" 

Figure  2.1  illustrates  the  definition  of  one  operand  type 
(bool)  and  the  operations  (not,  and,  true,  false)  that  are 
allowed  with  this  operand.  The  operations  are  stated  as 
functions  with  their  input  and  output.  Note  here  that  the 
constants  resembling  "true"  and  "false"  are  obtained  from  the 
nullary  operator  functions  with  no  input  ("trueO"  and 
"falseO").  Up  to  this  point  only  the  interface  part  is 
considered.  The  meaning  of  the  specification  is  indirectly 
in  the  form  of  equations  that  state  that  certain  expressions 
must  be  treated  identically  to  other  expressions.  The  above 
equations  use  "x"  as  a  free  variable,  i.e.  "x"  stands  for  any 
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expression  that  can  represent  an  operand  of  type  "bool".  So 
far  this  computer  resource  "boolean"  is  an  abstract  data  type 
in  the  traditional  meaning.  But  computer  resources  also 
consists  of  physical  resources  which  are  very  similar  to 
abstract  data  types  in  their  specification.  Figure  2.2 
provides  an  example  of  specifying  a  physical  computer 
resource  to  indicate  the  memory  state  of  the  Abstract 
Processor.  For  simplicity  only  the  operands  for 
initialization,  fetching  and  storing  are  presented.  The  first 
interesting  fact  to  note  in  this  specification  is  that  it 
states  that  the  resource  "amstate"  is  an  extension  of  the 
previously  defined  specifications  of  the  resources  "boolean", 
"memaddress",  and  "regaddress",  i.e.  all  operands,  operators, 
and  properties  defined  in  these  specifications  can  be  used  to 
specify  "amstate"  without  further  explanations.  The  operand 
"state"  has  in  this  example  four  operators  to  initialize  the 
processor,  to  fetch  from  memory  and  registers,  and  to  store 
to  memory  and  registers.  The  properties  for  these  operations 
are  shown  by  equations  that  indicate  their  relations  among 
them.  Note  that  this  example  uses  the  term  "undefined"  to 
indicate  an  error  or  don't  care  condition  (the  attempt  to 
fetch  the  contents  of  an  register  or  memory  address  of  a  new 
initialized  processor  is  illegal). 

The  basic  step  in  becoming  familiar  with  formal 
specifications  is  to  consider  the  well-known  constructs  of 
abstract  data  types:  a  class  of   objects  together   with  a  set 
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of   operations   that   may   be   applied  to  these  objects.  This 
approach  can  also  be  applied  to  physical  computer  resources. 


Resource  amstate   is 

Extension  of 

boolean, 

memaddress, 

regaddress, 

Operands 

state; 

Opera  tors 

fetchm:  memaddr , state    ->    val; 

fetchr:  regaddr , state    ->    val; 

s tor  em:  val , memaddr,  state    ->   state; 

storer:  val ,  regaddr,  state    ->    state; 

initam:  ->   state; 

Properties 

fetchm (a,  ini tarn (J )    is   undefined ; 
storem( fetchm(a,  q) ,  a,  q)    =    q; 
impl ies (eqmemaddr (al , a2) , 

fetchm(al , storem(v,  a2,  q) )    =  v) 

*  trueO; 
impl ies (not (eqmemaddr (al , a2) , 

fetchm(al, storem(v,a2,  q) )    =    fetchm(al ,  q) ) 

-  true(); 

fetchr(r,initam())    is   undefined; 
storer (fetchr (r,  q) , r, q)    -    q; 
impl ies (eqregaddr (rl , r2) , 

f etchr (rl , storer (v, r2,  q) )    =    v) 

-  trueO; 

impl ies (not (eqregaddr (rl ,  r2) , 

fetchr (rl, storer (v, r2,  q) )    -    f etchr (rl ,  q) ) 
=    trueO; 

end  amstate; 

Figure  2.2:  Specification  of  "amstate" 
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Then  we  have  concrete  algebras  which  describe  an  aggregate  of 
operations  and  sets  of  values  where  the  sets  are  the  source 
for  arguments  and  result  types  of  each  operation.  This  is  a 
system  in  which  there  are  sets  and  operations  that  are 
applied  to  elements  of  the  sets  such  that  the  results  of  the 
operators  stay  in  the  system.  When  we  construct  a 
specification  of  such  a  system,  we  attempt  to  create  a 
specification  that  serves  as  templates  for  the  sets  and 
operators  in  a  concrete  algebra  and  axioms  which  state 
provable  equations  about  the  values  and  operations.  With  such 
a  specification  we  have  something  which  describes  the 
resource  abstractly  and  precisely  without  restricting  it  to  a 
specific  concrete  algebra,  i.e.  there  can  be  many  algebras 
that  are  implementations  of  a  single  specification.  They  are 
considered  as  the  class  of  algebras  uniquely  associated  to 
that  specification. 

1 .   Syntax  versus  Semantics 

We  refer  to  the  syntax  of  description  as  the  "form" 
of  the  description  and  to  semantics  as  the  "meaning"  of  the 
descr  ipt ion. 

The  meaning  is  always  determined  by  associating  form 
to  real  objects.  Basically  the  syntactic  part  describes  legal 
expressions  that  can  be  formed  with  the  operators  in  the 
specification.  These  expressions  are  called  formal  terns.  The 
constraint  part  specifies  that  certain  formal  terms  are  to  be 
considered   equivalent.   The   meaning   of   specifications   is 
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established  by  associating  certain  concrete  algebras  to  the 
specification.  There  algebras  represent  the  "real  object". 
Operational  expressions  in  the  concrete  algebras  are  called 
actual  terms.  Semantics  are  defined  by  a  correspondence 
between  properties  of  formal  terms  and  actual  terms.  A  real 
object  is  a  realization  of  the  abstract  object  defined  by  a 
specification  under  three  conditions  as  they  are  stated  in 
Davis  and  Yurchak  (1984): 

-  Condition  1: 

For  each  operand  type  of  the  specification  there  is  a 
corresponding  set  of  values  in  the  real  object  and  to 
each  operator  in  the  specification  there  is  a 
corresponding  operation  in  the  real  object  that  is 
defined  on  values  that  correspond  to  the  operand  types  of 
the  operator. 

-  Condition  2: 

In  the  correspondence  between  formal  terms  and  actual 
terms,  two  formal  terms  are  provably  equal  if  and  only  if 
their  corresponding  actual  terms  have  the  same  value. 

-  Condition  3: 

To  every  value  of  the  real  object  there  must  correspond 
some  formal  term  whose  corresponding  actual  term  has  that 
value. 

These  conditions  provide  us  with  a  powerful  insight: 
given  a  formal  specification  of  some  resources  there  can  be 
different  implementation  in  the  real  world  (as  they  probably 
are  on  different  machines),  but  as  long  as  the 
implementations  satisfy  the  above  conditions  they  are 
equivalent.  This  is  a  very  important  property  when  the  issue 
of  portability  is  concerned. 

Still  an  formal  specification  despite  its  abstract 
view  of  resources   has   to   deal   with   the   real   world:  for 
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example  there  is  nothing  like  true  infinite  memory  so  that  a 
defined  operator  like  "nextroemaddr"  (to  obtain  the  memory 
address  of  the  next  instruction  to  be  executed)  will 
eventually  exceed  the  physical  implemented  memory  of  a 
system.  The  nundef  ined**  has  been  introduced  in  the  formal 
specifications  to  act  like  a  safeguard.  It  indicates  that 
there  is  no  interpretation  in  the  realization  for  this  term. 

B.   PETRI  NETS 

Petri  Nets  are  tools  for  the  study  of  systems  through 
modeling.  The  Petri  Net  theory  has  been  originally  introduced 
by  Carl  Adam  Petri  in  his  doctoral  dissertation  (1962). 
Further  studies  of  A.  W.  Hold  and  Jack  B.  Dennis  helped  to 
develop  this  theory. 

1 .   Terminology  of  Petri  Nets 

From  Peterson  (1981)  a  basic  Petri  Net  is  defined  as 
a  five-tuple  M  =  (P,T, l,0,m)  which  is  composed  out  of  the 
following  parts: 

-  a  set  of  places  P 

-  a  set  of  transitions  T 

-  an  input  function  I 

-  an  output  function  0 

-  a  marking  vector  m 

The  function  I  is  a  mapping  from  a  transition  t,  to  a 
collection  of  input  places  0(tj)  and  the  function  0  is  a 
mapping  of  a  transition  t,  to  a  collection  of  output  places 
I(ti),  the  marking  vector   m  indicates   the  number   of  tokens 
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preset  in  each  place.  In  this  general  form,  developed  by  C.A„ 
Petri,  a  place  can  hold  more  than  one  token  at  a  time.2 

As  an  example,  the  following  net  structure  is 
presented  here  and  Figure  2.3  shows  its  corresponding  graph 
in  the  common  symbology  of  Petri  Net  graphs  where  circles 
indicate  places,  bars  indicate  transitions,  and  arrows  show 
the  connections  between  places  and  transitions: 
M  =  (P,T, I ,0,m) 

P  =   {  P>  »  P2  t   P-3  .  P«  »  Ps  >  P6  »  P?  ,  Pa  > 
T  =  (t,  ,  t2  ,  t3  ,  t4  .  ta  } 
m  =  (1,0,0,0,0,0, 0, 0) 

I  ( t»  )  =  {p,  )  0(tt  )  =  {p2  ,  p4  ) 

I Ct2 )  ■  {pi  )  0(t2 )  =  (p3 } 

I  (t3  )    =    (P2  ,P3  }  0<t3  )    =    (p3  ,p6  } 

I  (  t«  )    =    (P4  ,P5  }  0(t4  >    =    (P7  } 

I  (  ta  >   =   fp*  ,  P7  >        0( t9  )   =   tpa  > 


t2      p3      t3      p6 


Figure  2.3:  Graph  of  Petri  Net 


The  following  Petri  Net  terminology  is  used  in  this  thesis: 

-  place  =  a  construct  for  modeling  conditions  of  the  system 

-  event  =  actions  that  take  place  in  the  system 

-  token  =  a  construct  used   to   indicate   that   a  condition 
holds  (a  true  condition) 


2The  reader  is  referred  here  to  the  BAG  theory 
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-  transition  =  the  process  of  recognizing  true 
preconditions,  the  occurrence  of  an  event,  and  making  the 
postconditions  hold 

-  concurrency  *  two  or  more  events  depending  on  different 
preconditions  can  occur  in  any  order 

-  conflict  =  only  one  of  two  or  more  events  depending  on  at 
least  one  common  precondition  can  occur 

To  give  a  simple  description  of  Petri  Nets  we  can  say  the 

following:  An  event   occurs   (a   transition   is   initiated  or 

enabled)  when   all  of   its  preconditions   hold.  The  effect  of 

the  occurrence  is  that   the  tokens   of  the   preconditions  are 

"used"    for    the    event    and    then   distributed   to   the 

postcondi  t ions. 

The  following  constructors  can  be  recognized  in  Petri  Nets: 

-  simple  transitions  B  there  is  one  precondition  and 
whenever  this  condition  holds  the  event  occurs  so  that 
the  token  from  the  precondition  is  removed  and  after  the 
occurrence  of  the  event  the  token  is  moved  to  the 
postcondition  so  that  this  condition  now  holds  (Figure 
2.4). 

-  conjunctive  transitions  =  there  are  two  or  more 
preconditions  that  all  have  to  hold  in  order  for  the 
event  to  occur.  All  tokens  of  the  preconditions  are  used 
and  after  the  occurrence  of  the  event  only  one  token  is 
moved  to  the  postcondition  to  indicate  that  it  now  holds 
(Figure  2.5). 

-  disjunctive  transitions  ■  one  precondition  is  connected 
to  two  or  more  events  and  when  this  precondition  holds 
one  of  the  events  will  occur  and  will  move  the  token  from 
the  precondition  to  the  postcondition  of  that  event  that 
occurred.  The  selection  of  the  event  to  occur  is 
non=determinist ic  (Figure  2.6). 

-  distributive  transitions  =  there  is  one  precondition  and 
when  this  holds  the  connected  event  will  occur.  It  will 
remove  the  token  from  the  precondition  and  it  to  all 
postconditions  so  that  every  postcondition  of  this  event 
will  have  a  token  (Figure  2.7). 

-  complex  transitions  *  combinations  of  the  above  simple 
constructs  of  Petri  Nets. 
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Figure  2.4:  Simple  Transition 
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Figure  2.5:  Conjunctive  Transition 
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Figure  2.6:  Disjunctive  Transition 
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Figure  2.7:  Distributive  Transition 


2.   Properties  of  Petri  Nets 

Petri  Nets  by  their  nature  are  well  suited  to  model 
asynchronuous  processes,  i.e.  where  the  progress  of  a  process 
is  controlled  by  conditions  and  events  and  not  by  some  kind 
of  fixed  clock.  This  means  that  in  some  part  of  the  net  there 
can  be  waiting  for  a  condition  to  start  an  event,  even  the 
case  that  a  process  cannot  continue  because  of  a  missing 
condition.  Suppose  an  event  is  modeled  as  a  conjunctive 
transition  as  indicated  in  Figure  2.5.  If  the  precondition 
Cp r . i  is  never  true  the  process  will  stop  at  this  point.  The 
"flow"  of  the  progress  can  always  be  observed  by  the  state  of 
the  condition  places  in  the  system.  The  occurrence  of  events 
is  recognizable  by  the  changing  of  the  preconditions  and 
postconditions. 
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The  discussion  of  disjunctive  events  has  shown  an 
important  property  of  Petri  Nets:  their  non-deterministic 
nature,  i.e.  we  have  under  normal  circumstances  to  force  a 
distributive  construct  in  one  or  the  other  direction.  This  is 
a  major  obstacle  when  we  have  to  model  some  kind  of  decision 
making  in  a  Petri  Net.  One  way  to  get  around  this  problem  is 
the  construct  (introduced  by  Peterson  (1981))  of  an  "external 
agent"  which  provides  appropriate  TRUE  or  FALSE  places  at 
decision  points  in  the  net.  Here  by  the  intervention  of  the 
"external  agent"  the  process  proceeds  in  the  direction  of  the 
TRUE  or  FALSE  place.  In  general,  one  can  think  of  "external 
agents"  as  CASE-constructs  in  high-level  programming 
languages  such  that,  dependent  on  the  value  of  an  argument, 
one  and  only  one  action  is  taken  by  setting  the  according 
place  in  the  net.  We  will  discuss  this  topic  further  in 
Chapter  IV. 

When  we  look  at  the  conjunctive  and  distributive 
constructs  we  observe  that  by  combining  them  we  can  build  a 
distributive  construct  which  "fans"  out  into  several  holding 
places  and  then  combines  again  with  a  conjunctive  construct. 
In  this  way,  we  have  able  to  introduce  paralleli«m  into  Petri 
Nets.  Figure  2.8  shows  the  graph  of  a  process  that  fans  out 
into  five  processes  which  then  merge  again  into  one  process. 
This  capability  of  Petri  Nets  is  very  powerful  and  convenient 
in  specifying  computer  resources. 
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Figure  2.8:  Parallelism  with  Petri  Nets 


3.   Modeling  with  Petri  Nets 

Modeling  with  Petri  Nets  has  been  widely  used  in  very 
different  areas:  computer  software,  computer  hardware, 
chemical  reactions,  queuing  theory,  political  systems,  etc.. 
Two  examples  as  they  are  presented  by  Peterson  (1981)  are 
given  to  illustrate  this  modeling  work:  a  portion  of  a  Petri 
Net  showing  a  control  unit  of  a  computer  with  multiple 
registers  and  functional  units  as  an  example  for  modeling 
computer  hardware  (Figure  2.9)  and  a  Petri  Net  dealing  with 
the  mutual  exclusion  problem  as  example  for  modeling  computer 
software  (Figure  2.10). 

In  our  approach  we  want  to  exploit  the  ease  and  the 
properties  of  Petri  Nets  for  modeling  the  combination  of 
computer  hardware  and  software  as  they  operate  in  time. 
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Figure  2.9:  Computer  Control  Unit 


Figure  2.10:  Mutual  Exclusion 
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III.  THE  PROBLEM  OF  TIMING  SPECIFICATION 

A.   GENERAL  PROBLEMS 

Why  are  we  so  concerned  about  the  timing  of  a  system? 
Time  is  an  important  resource  in  computer  systems  that  must 
be  managed  carefully.  There  is  almost  always  the  possibility 
that  if  we  invest  more  of  other  resources  we  are  able  to 
reduce  the  amount  of  time  a  piece  of  work  will  need. 
Everybody  remembers  a  mathematical  problem  like  this:  if  it 
takes  one  unit  to  accomplish  a  task  in  x  hours  how  many  hours 
will  it  take  y  units  to  do  the  same  task?  In  this  very  simple 
problem  the  increase  of  other  resources  (e.g.  units)  will 
reduce  the  needed  time  for  the  task  linearly. In  computer 
systems  we  could  save  time  by  implementing  more  CPUs,  disk 
drives,  arithmetic  units,  etc..  But  since  more  hardware  costs 
more  money  and  the  control  of  additional  resources  uses  time 
by  itself  we  have  to  be  very  careful  in  determining  the 
resources  we  need  and  how  we  use  them.  The  following  example 
shows  the  danger  of  mismanaging  computer  resources:  a 
computer  task  that  requires  some  resources  (e.g.  disks)  would 
waste  them  if  it  holds  more  than  it  needed  at  times  when  it 
actually  does  not  need  them  and  so  prohibits  other  tasks  from 
using  them. 

The  formal  specification  as  described  in  the 
specification   of   the   Abstract   Processor  is  only  concerned 
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with  static  computer  resources,  i.e  the  timing  properties  are 
implied  by  the  functional  relations  between  components  of  the 
system.  The  static  specification  is  purely  functional.  For 
example,  operands  must  be  evaluated  before  a  function  is 
applied  but  there  is  no  way  of  indicating  the  order  of 
evaluation.  The  dynamic  computer  resources  are  those  that 
express  an  ordering  of  resources  in  time,  mutual  exclusion 
and  concurrency.  Instead  of  assuming  some  ordering  in  the  use 
of  computer  resources  we  want  to  be  able  to  explicitly  state 
and  define  the  timing  of  a  system. 

The  goal  is  to  specify  the  required  timing  properties 
precisely  to  a  desired  degree  which  for  example  is  sufficient 
to  evaluate  the  system  for  time  and  cost  efficiency.  The 
relation  between  time  and  cost  depends  on  the  nature  of  the 
system:  there  is  much  more  emphasis  on  time  in  system  that 
are  very  time  critical  (e.g.  real-time  systems)  and  not  so 
much  on  systems  that  are  purely  problem  solvers. 

The  basis  of  this  work  is  to  show  whether  such  a 
methodology  for  specifying  timing  properties  can  be  based  on 
the  theory  of  Petri  Nets  and  how  well  the  special  cases  of 
timing  in  computer  system  resources  can  be  expressed  in  terms 
of  Petri  Nets. 
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B.   SPECIFIC  PROBLEMS  OF  INTEREST 

1 .  Order  of  Evaluations  of  Functions 

Given  a  function  f < x( , x2 , . . . , x„ )  we  only  require  that 
x»  to  x„  are  evaluated  before  f  can  be  applied.3  There  is  no 
statement  that  the  evaluation  of  x»  has  to  be  started  first 
or  what  evaluation  has  to  be  completed  first. 

2.  Parallel  Processing  of  Parts  of  Functions 
Considering   again   our   function   f (x» , x2 , . . . , x„ )  we 

want  to  state  explicitly  which  evaluations  have  to  performed 
in  parallel  and  which  in  sequence.  Why  do  we  want  to  do  so? 
Following  our  purpose,  in  the  specification  we  want  to 
describe  timing  in  a  way  which  is  as  exact  and  detailed  as  a 
timing  diagram  used  to  construct  hardware. 

3.  Mutual  Exclusion 

A  major  problem  that  arises  with  parallelism  is 
mutual  exclusion,  i.e.  a  computer  resource  can  only  be  used 
by  one  process  at  a  time  and  the  use  of  the  resource  has  to 
have  a  certain  entry  and  exit  point  to  preserve  the  integrity 
of  the  resource. 

Consider  a  simple  computer  with  a  memory  unit  which 
retrieves  and  stores  data  on  request  via  a  specified 
interface  (Memory  Buffer  Register  and  Memory  Address 
Register).  This  is  parallelism  even  in  simple  computers  since 
the  memory   is  independent   from  the   CPU.  So  we  have  to  make 


3Even  if  x  is  a  constant  it  has   still  to   be  evaluated, 
i.e.  its  value  has  to  be  retrieved 
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sure  that  only  one  request  is  handled  by  the  memory  unit  at  a 
time  and  that  the  next  one  is  handled   when  the   first  one  is 
finished.   We   want   to   be   able   to   explicitly  state  those 
properties  in  the  specification  of  timing  systems. 
4.   Data  Flow 

During  the  course  of  a  process  in  time  certain  data 
has  to  be  available  in  order  for  the  process  to  proceed.  Some 
data  is  changed,  other  data  is  not  needed  anymore.  Here  we 
have  the  problem  of  how  to  model  data  flow  by  means  of  Petri 
Nets. 

To  make  this  point  more  clear  let  us  consider  the 
execution  of  following  instruction:  SUB  R1,R2  (subtract  the 
contents  of  register  1  from  the  contents  of  register  2  and 
store  the  result  in  register  2).  During  the  execution  we  have 
to  retrieve  the  identities  of  the  registers  from  the 
instruction  (i.e.  the  instruction  has  to  be  decoded)  then 
their  contents  both  have  to  be  available  before  we  can 
perform  the  subtraction.  At  this  point  of  the  execution  we  do 
not  need  the  identity  of  the  first  register  anymore,  but  the 
one  for  the  second  since  it  is  not  only  a  source  for  the 
operation  but  also  the  destination.  Thus,  we  have  to  have 
some  mechanism  in  our  methodology  to  state  data  which  is 
available  during  the  course  of  the  execution. 
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IV.  APPLICATIONS  OF  PETRI  NETS  TO  THE  TIMING  IN  FORMAL 

SPECIFICATIONS 

In  previous  work  computer  resources  have  been  formally 
specified  using  basically  the  algebraic  specification 
approach.  In  essence,  this  is  a  type  of  functional 
specification.  The  question  we  address  here  is  can  functional 
specification  be  extended,  using  Petri  Net  theory,  to  provide 
for  the  specification  of  timing  properties. 

A.  GENERAL  APPROACH 

Given   a   general   function   f <xt » x* , . . . > x„ )  what  are  the 
stages  of  evaluation  for  this  function? 

-  the  evaluation  of  f <Xi , x2 , . . . , x„ )  must  have  been 
requested  from  somewhere  and  by  this  the  evaluation  gets 
into  a  requested  stage 

for  *U  x,,  i  <■  i  <=  n,  the  evaluation  is  requested 
which  starts  for  all  xt  a  new  process  with  the  same 
stages  as  described  here 

-  once  all  x,  are  evaluated  and  their  results  are  available 
to  our  function  f  it  can  be  evaluated  in  a  processing 
stage 

-  when  the  evaluation  is  completed  and  the  result  is 
available  the  process  is  completed 

Note  the   similarity  to   the  "natural"   way  a  human  being 

would   calculate   this   function:   if   we   were   to  calculate 

sum( sin< x2  ) , sqrt(y) )    we  had  to  calculate  the  square  root  of  y 

and  we  had  to  square  x  and  take   the  sine   of  it   and  then  we 

would   apply   the   sum-function   to  the  intermediate  results. 


29 


However,  this  example  exhibits  a  problem  for  our  very  general 
approach:  how  do  we  know  what  the  values  of  x  and  y  are  and 
how  do  we  know  that  e.g.  nsqrtn  means  "take  the  square  root". 
Therefore  there  must  be  some  decoding  and  retrieval  steps  in 
between  which  determine  what  the  parts  of  the  function 
expression  mean.  This  is  exactly  the  case  when  we  consider 
computer  instructions:  e.g.  given  an  instruction  like  nADD  Rl 
M2  R3"  which  means  "add  the  contents  of  register  1  to  the 
contents  of  memory  address  2  and  store  the  result  in 
register  3".  Here  the  following  steps  have  to  be  performed: 

-  The  instruction  has  to  be  decoded  (we  assume  that  at  this 
stage  the  instruction  is  already  retrieved):  i.e.  the 
components  of  the  instruction  (operator  and  operands) 
must  be  made  available  to  the  further  evaluation. 

-  Up  to  this  stage  only  the  names  (i.e.  the  symbolic 
addresses)  of  the  operands  are  available  and  so  the  next 
step  is  to  retrieve  the  values  of  the  operands. 

-  Now  that  the  operator  and  the  values  of  the  operands  are 
available  the  operation  designated  by  the  operator  can  be 
performed. 

-  When  the  result  is  available  it  can  be  stored  into  the 
location  which  expressed  by  the  third  operand. 

Figure  4.1   shows  the   corresponding  graph  of  a  Petri  Net 

describing   the   above   steps.   In   this   example   we   see  an 

approach   to   describe   the   execution  of  an  instruction  in  a 

sequential   manner.   Suppose   we   had   a   machine   that  could 

perform  retrieval   of  values   and  operation  in  parallels,  how 

could  we  describe  that   certain  steps   could  be   performed  in 

parallel   and   how   could   we   mark   points  in  time  where  the 

process  can  only  proceed  if  some  results  are  available? 
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Figure  4.1:  Simple  Instruction  Execution  Net 

This  is  the  point  where  we  can  use  the  properties  of 
Petri  Nets:  if  we  model  requests  and  availabilities  as  places 
of  Petri  Nets  and  the  actions  on  requests  and  availabilities 
as  transitions  and  connect  them  accordingly  we  are  in  a 
position  to  model  the  evaluation  of  a  function  or  the 
execution  of  an  instruction. 

Up  to  this  point  there  is  nothing  new  in  our  methodology 
since  modeling  with  Petri  Nets  is  common  practice  and  has 
been  done  for  a  long  time.  The  question  to  be  ask  now  is  does 
a  methodology  based  on  Petri  Nets  provide  the  means  to 
specify  the  specific  problems  of  computer  systems  and  their 
components  in  a  way  that  is  consistent  with  the  formal 
specification  of  the  static  properties  we  have  seen  in  the 
specification  of  the  Abstract  Processor. 

In  addition  we  not  only  want  to  look  at  the  timing  of 
systems  in  an  isolated  fashion,  but  also  we  want  to  combine 
the  specification   of  static  properties,  as  introduced  in  the 
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specification  of  the  Abstract  Processor,  with  the 
specification  of  dynamic  properties  of  such  a  system.  With 
this  combination  we  can  specify  systems  completely. 

B.   NOTION  OF  SUBNETS 

Now  that  we  have  Petri  Nets  as  a  tool  we  can  model  simple 
timing  systems  using  our  methodology.  However,  we  would  like 
to  simplify  and  eliminate  redundancy:  if  we  use  the  same 
structure  in  a  net  several  times,  it  would  be  better  to  have 
this  structure  defined  once  and  reference  this  definition 
wherever  we  need  it  in  our  system  (Figure  4.2).  As  an 
example,  suppose  we  realize  that  a  structure  to  make  the 
contents  of  a  certain  memory  address  available  to  the  process 
appears  several  times  in  our  system.  By  defining  this 
retrieval -function  as  a  subnet  we  are  in  a  position  to  use  it 
everywhere  in  the  system  simply  by  setting  its  ENTRY-place 
(in  our  example  with  a  request  for  value  of  a  specified 
register)  and  we  obtain  the  result  (the  value  of  the 
specified  register)  at  its  EXIT-place.  This  works  even  for 
the  case  that  the  subnet  specifies  a  computer  resource  that 
has  to  be  accessed  observing  mutual  exclusion. 

The  major  question  that  has  to  be  asked  here  is  how  can 
we  model  such  a  subnet  that  has  the  ability  to  "sense"  where 
it  has  been  invoked  and  so  can  return  its  results  to  that 
location  in  the  system.  Computer  language  constructs  like 
procedures  or  functions  use  a  return  address  which  is  saved 
with   the   call   of   the   procedure/function  to  determine  the 
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location  in  the  program  which  has  to  be  executed  after  the 
procedure/function  is  finished.  Our  model  of  using  Petri  Nets 
is  different  in  this  aspect:  despite  the  fact  that  it  shows 
the  dynamic  behavior  of  a  system,  its  structure  is  static  and 
does  not  change  in  time  and  so  all  connections  between  nets 
and  subnets  are  established.  Since  we  have  to  know  al 1  these 
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Figure  4.2:  Symbology  of  Subnets 


connections  we  are  able  to  provide  for  each  connection  an 
entry-place  which  is  connected  to  the  net  internally  by 
disjunctive  events  such  that  only  one  can  be  "fired"  at  a 
time.  The  "firing"  of  those  events  lets  a  path-place  hold 
that  indicates  the  entry-place  which  triggered  the  event. 
This  path-place  decides  what  exit-place  is  set  when  the 
internal  net  provides  the  result. 

This  definition  of  a  subnet  is  a  very  powerful  shortcut 
for  keeping  descriptions  of  systems  limited.  It  resembles  a 
function  construct  in  a  high-level  programming  language:  it 
is   been   "called"   by   setting   its   request-place,  does  its 
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supposed  work  and   "returns"   the   result   as   the  available' 
p lace. 
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Figure    4.3:    Generalized    Subnet    without    Mutual    Exclusion 
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Figure    4.4:    Generalized    Subnet    with    Mutual     Exclusion 
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We  have  to  show  that  our  methodology  is  capable  of 
defining  subnets  and  introducing  them  into  other  nets. 

C.   COMBINING  NETS 

With  the  introduction  of  subnets  we  are  in  need  of  rules 
and  guidelines  on  how  we  can  combine  a  collection  of  small 
nets  and  subnets  into  a  timing  system. 

1 .   Coupling  of  Nets 

In  the  preceding  paragraph  we  have  assumed  that  nets 
are  connected  by  entry  and  exit  places,  but  generally,  we 
have  two  possibilities  to  connect  nets: 

-  Coupling  by  places:  to  connect  two  nets  the  first  net 
outputs  to  a  EXIT-place  that  is  read  by  the  second  net  as 
an  ENTRY-place.  In  the  special  case  that  we  use  subnets 
in  our  specification  we  request  the  subnet  by  place  (the 
ENTRY-place  of  the  subnet)  and  obtain  the  result  by  a 
place  (the  EXIT-place  of  the  subnet). 

-  Coupling  by  events:  events  are  shared  between  nets  and 
when  the  ENTRY-event  "fires"  the  requested  net  is  invoked 
and  signals  the  availability  of  the  result  by  "firing" 
its  EXIT-event. 

We  have  chosen  the  coupling  of  nets  by  places  because 

of  the  following  reasons: 

-  The  request  for  a  subnet  submitted  by  a  place  allows  the 
requested  subnet  more  "liberty"  to  react  on  the  request 
only  when  it  is  ready  to  do  so  since  the  pending  request 
as  a  "loaded"  place  remains  until  it  is  used  by  the  net, 
where  as  in  event-coupling  the  saving  requests  had  to  be 
done  in  a  more  complicated  way. 

-  The  coupling  of  nets  by  places  resembles  the  way  events 
like  interrupts  are  processed  in  real  machines,  here  the 
interrupt  does  not  interrupt  the  execution  of 
instructions  at  any  time,  but  a  status  "interrupt"  is  set 
and  this  status  is  checked  between  the  execution  of 
instructions  and  acted  upon. 
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2.  Extensions  of  Nets 

To  make  our  methodology  consistent  we  need  to  state 
what  other  nets  we  are  going  to  use  in  this  net.  There  is  a 
close  similarity  to  INCLUDE,  USE  or  WITH  constructs  of  high- 
level  programming  languages  or  the  EXTEND  construct  of  the 
formal  specification.  In  the  specification  of  timing  the 
mentioning  of  a  net  to  be  the  extension  of  another  means  that 
the  parent  net  is  going  to  use  the  extended  net  as  a  subnet 
in  the  specification. 

3.  Net  Selection 

Due  to  the  non-deterministic  nature  of  Petri  Nets  we 
do  not  have  a  traditional  net  construct  which  can  make 
decisions  on  truth  or  falseness  and  directs  the  path  in  the 
net  accordingly.  A  proposed  solution  for  this  problem  by 
Peterson  (1981)  is  to  use  "external  agents"  as  they  were 
presented  in  Chapter  2.  This  construct  is  able  to  examine  a 
status  or  data  on  a  given  condition  and  make  the  decision 
whether  the  condition  is  fulfilled.  With  the  outcome  of  the 
decision  a  path  to  a  place  representing  true  or  the  place 
representing  false  is  set.  By  extending  this  idea  we  able  to 
think  of  "external  agents"  as  a  CASE-statement  where  one  and 
only  way  through  the  net  is  chosen  according  to  a  condition 
(see  Fi  gure  4.5). 

D.   TYPING  OF  NET  ELEMENTS 

In   the   traditional   Petri   Net  theory  we  have  tokens  to 
indicate  the  flow  through  the  net  and  to  mark  holding  places. 
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So  the  "firing"  of  an  event  consists  in  collecting  a  token 
from  each  of  the  connected  input  places,  performing  the 
designated  action  and  distributing  a  token  to  each  connected 
output  place.  This  is  not  enough  when  we  want  to  describe  the 
flow  of  data  in  time.  Also  we  want  to  be  able  to  state 
specifically  what  kinds  of  data,  what  types  of  data  are  being 
requested,  available  or  transferred  at  a  certain  point  in  the 
timing  of  a  system. 


avail  net 


re<^_net  [msg=v] 


External  Agent 
Figure  4.5:  Net  Selection  by  "external  agents 


How  can  we  show  the  presence  of  data  in  our  methodology? 
On  first  sight  we  have  two  possibilities:  either  we  introduce 
a  typed  place  or  a  typed  token.  Both  of  these  constructs 
could  indicate  the  presence  of  certain  data.  So  we  to  examine 
both  methods   under  the  consideration  which  of  them  suits  our 
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goal   better    to   develop   a   practical   and   understandable 
methodol ogy . 

1 .  Typed  Places 

When  we  introduce  a  concept  of  typed  places  we  still 
have  the  original  meaning  of  the  tokens  to  indicate  the 
holding  of  a  place.  The  presence  of  data  of  a  certain  type 
must  be  accomplished  by  means  that  have  to  obey  the  type  of 
the  place.  The  events  still  react  on  the  presence  of  tokens 
in  the  places. 

2.  Typed  Tokens 

This  alternative  considers  a  token  as  a  construct 
that  carries  an  actual  piece  of  data  according  to  the  type  of 
the  token.  We  can  imagine  tokens  as  a  message  residing  in  the 
places.  The  events  now  can  be  modeled  by  picking  up  a  message 
from  each  connected  input  placed,  performing  their  designated 
actions,  and  distributing  a  message  to  every  connected  output 
pi  ace. 

So  now  we  can  look  at  places  in  a  net  as  constructs 
that  can  receive  token-messages  from  events,  keep  them  and 
send  them  to  events.  The  actions  performed  by  events  consist 
of  picking  up  message-tokens  from  places,  changing  and 
creating  message-tokens  and  sending  them  to  places. 

3.  Typed  Tokens  in  Typed  Places 

Both  concepts  above  exhibit  some  disadvantages: 

-  Pure   place   typing   needs   some   external   mechanism   to 
establish  the  presence  of  data. 
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-  Pure  token  typing  allows  a  message-token  to  be  sent  to 
every  place  in  the  net  since  there  no  protection  from 
receiving  message-tokens  of  the  wrong  type. 

This  leads   to   the   idea   of   combining   both  typing 

schemes.  With   this  concept   we  restrict  places  in  the  net  to 

accept  only  tokens  of   a   certain   type   and   the   tokens  are 

actually  typed   messages.  One   small  problem  does  arise  here: 

what  if  we  want  in  some   situations   the   token   to   have  its 

original  meaning   only  to   indicate  its   presence  without  any 

data?  This   reminds   of   a   message   without   contents.   As  a 

solution  we  introduce  following  typing  convention: 

-  A  place  declared  to  be  of  a  certain  type  or  collection  of 
types  can  only  accommodate  tokens  that  are  messages  of 
this  type  or  collection  of  types. 

-  A  place  declared  to  be  of  no  type  can  only  accommodate 
tokens  which  are  "empty"  messages. 

-  An  event  will  collect  typed  token-messages  from  the 
connected  typed  input-places,  perform  its  designated 
action  and  output  typed  token-messages  to  the  connected 
typed  output-places. 

With  this   typing  scheme  we  are  now  in  a  situation  to 

specify  data  flow   in   time   by   means   of   typed   tokens  and 

places.  Although   we  have  based  our  work  on  Petri  Nets  we  see 

that  our  concept  has  become  more  general  and  now  reminds  of  a 

general  message  passing  system. 

E.   SYNTAX 

Since  our  approach  includes  the  existing  specification 
methodology  of  the  static  computer  resources,  we  have  to 
carefully  develop  a  new  syntax  which  expresses  both  the 
static  and  dynamic  properties  of  the  systems  to  be  specified. 
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The    following    syntax    has    been    introduced   with   the 

specification  of  the  Abstract  Processor  by   Davis  and  Yurchak 

(1985) : 

Resource  <name>  is 
Operand  Types 

<operand  types> 
Operators 

<operators> 
Properties 

<properties> 

The  following  requirements  have  to  be  fulfilled  by  the 
syntax  we  want  to  develop: 

-  It  has  to  have  the  ability  to  express  both  the  static  and 
dynamic  properties  of  system  properties  where  the  static 
part  should  be  left  in  the  form  as  introduced  by  Davis 
and  Yurchak  (1984). 

-  The  form  of  the  syntax  should  be  as  simple  and  easy  to 
understand  as  possible. 

-  The  chosen  names  of  the  constructs  of  the  syntax  should 
be  self-explanatory  and  suggest  the  intended  meaning  to 
the  user. 

-  It  has  to  provide  a  precise  and  unambiguous  way  to 
specify  the  system. 

Another  point  to  consider  is  that  we  want  to  follow 
certain  accepted  design  principles,  especially  that  of 
Information  Hiding  as  it  is  done  e.g.  in  the  ADA  package 
construct  where  there  is  a  Package  Interface  (to  provide  the 
user  of  the  package  with  all  the  information  necessary  to  use 
the  package  and  nothing  else)  and  a  Package  Body  (the 
implementation  of  the  package). 

Before  we  finalize  the  syntax  for  the  dynamic 
specification  of  a  system  we  need  to  say  something  about  how 
the   dynamic   properties   of   static  objects  are  described  in 
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terms  of  places  and  transitions.  Places  reflect  the 
conditions  on  the  execution  of  the  static  functions,  whereas 
transitions  are  used  to  describe  changes  in  these  conditions 
during  the  execution  of  the  static  functions.  Some  of  these 
places  and  transitions  are  generic,  i.e.  they  apply  to  any 
function.  For  example,  a  function  is  always  requested  by  a 
place  and  becomes  activated  by  an  act ivate- trans i t ion.  This 
does  not  prevent  us  from  defining  additional  places  and 
transitions  when  they  are  needed  for  a  specification.  We  are 
going  to  use  an  uniform  notation  to  indicate  the  connection 
between  the  statement  of  the  dynamic  properties  and  the 
static  properties.  Given  an  operator  storem  :  val,  memaddr, 
state  ->  state  we  will  use  internal  places  names  that  are 
preceded  by  storem__  (e.g.  storem_acti vated)  and  transition 
names  that  are  followed  by  _storea  (e.g.  acti vate_storem) .  We 
also  reserve  standard  notations  for  entry  and  exit  places  of 
subnets:  entry  places  are  always  preceded  by  req_  (e.g. 
req_storem  for  "request  a  store  in  memory'*)  and  exit  places 
are  always  preceded  by  avail_  (e.g.  avail_storem  for  "result 
of  store  in  memory  is  available).  We  reverse  the  order  of 
attaching  the  name  of  the  function  because  we  want  to 
emphasize  that  a  subnet  represents  a  transition  that  is 
specified  in  detail. 
1 .   P laces 

There   are    three   types    of   places    we   want   to 
distinguish  in  our  syntax: 
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-  internal  places*  which  names  and  definitions  are  only 
known  and  accessible  within  the  net  they  are  defined  in; 
the  purpose  is  to  build  the  internal  structure  of  the  net 

-  entry  places,  which  names  and  definition  are  also  known 
and  accessible  to  those  nets  which  are  declared  to  be 
extensions  of  this  net;  they  provide  an  interface  to 
invoke  this  net 

-  exit  places*  which  names  and  definitions  are  known  and 
accessible  to  those  nets  which  are  declared  to  be 
extensions  of  this  net;  they  provide  an  interface  to 
obtain  the  results  from  the  invocation  of  this  net 

We   have   chosen   the   following   syntax   to  describe 

places  in  our  specification: 

place_nane( net  label ) [«essage_type] . 

A  place_name  is  the  distinct  name  of  a  place  in  the  described 

net.  In   the  case   that  a   place  is   either  an   entry  or  exit 

place  the  rule  applies   that  their   names  are   known  to  those 

nets  which   are  declared   to  be   extensions  of  this  net.  If  a 

net  has  multiple  entry  or  exit  places  the   parameter  netlabel 

can  be   attached  in   parentheses  to   describe  this  fact  where 

netlabel  indicates  a  location  in  the  system.  As   we  have  said 

a  place   is  able   to  accommodate  a  certain  kind  of  message  so 

the  type  of  the   message  the   place  can   hold  in   brackets  is 

part  of   the  place   description.  The  following  description  of 

places  are  legal  (compare   with  the   static  specification  for 

"fetchr"  and  "storem"  in  Chapter  II): 

-  storem_acti vatedC val . memaddr. state] ;  a  place  of  the  name 
nstorem_act i vated"  which  can  hold  messages  that  consist 
of  data  of  type  val,  memaddr  and  state 

-  f etchr_avai 1 C ] ;  a  place  of  the  nf etchm_avai 1 w  which  can 
only  hold  empty  messages 
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-  req_pushstk(net label ) Cval . stkaddr. state];  places  of  the 
name  "req^ushstk"  which  are  distinguished  by  the 
parameter  "netlabel",  all  of  them  able  to  hold  messages 
which  contain  data  of  types  val,  stkaddr  and  state. 

2.   Transitions 

Our  methodology  defines  transitions  as  the  process  of 

collecting  a  message   from   each   connected   input   place  and 

sending  messages   to  every  connected  output  place.  So  we  want 

to  state  what  kind  of  messages  are  received   and  transmitted. 

The   following    syntax   is   used   to   describe   transitions: 

trans i tion_name: input_messages  ->  output_messages. 

The  trans i t ion_name  is  a  distinct  name  for  the   transition  in 

the  net   and  is   not  known   outside  the  net.  Input  and  output 

messages  are  of  the   above  form   where  multiple   messages  are 

separated   by    commas.   The   following   examples   are   legal 

description  of  transitions: 

-  perf orm_storem:  Cval . memaddr. state)  ->  (state!; 

the  transition  of  the  name  "perf orm^storem"  takes  a 
message  which  contains  data  of  type  val ,  memaddr  and 
state  as  input  and  outputs  a  message  containing  data  of 
type  state 

-  f inish_fetchr:  C va 1  ) , t 3  ->  [ va I  ] , [  ] ; 

the   transition   of   the   name   "f  inish_f  etchr**  takes  two 

messages  as  input  where  one  consists  of  data   of  type  val 

and  the  other  is  an  empty  message  and  outputs  again  two 
messages  of  same  type 

Note   that    the   description    of   transitions   only 

declares  them  in  terms  of  their  capabilities  to  accept  and  to 

transmit  certain  kinds  of   messages   and   does   not   show  any 

internal  action   of  the  transition.  The  reason  for  this  is  to 

present  the  transitions  as  building  blocks  of  the  net  in  form 

of   a   mapping   function   which   is  general  enough  to  provide 
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information  about  its  interface  and  nothing  more.  The 
interna]  actions  are  described  as  the  properties  of  the  net. 
This  does  not  necessarily  means  that  a  transition  is 
instantaneous,  rather  the  complexity  of  the  internal  actions 
determine  the  duration  of  the  transition.  But  every  complex 
transition  can  be  modeled  as  a  net  with  entry  and  exit  places 
such  that  the  internal  transitions  become  instantaneous. 
3.   Properties 

Now  that  we  have  described  the   building  blocks   of  a 
net  we  need  to  connect  them  in  order  to  describe  the  intended 
timing  of  a  system.  The   following   form   is   chosen   for  the 
syntax  of  the  properties  of  the  net: 
trans  i  t  i  on_naae ( p 1 ace_names C me  s  sage_da  t a )  =  > 

place_naaesCmessage_dataJ ;  This  form  shows  how  places  and 
transitions  are  connected  and  how  the  transfer  of  message 
elements  occurs  between  them.  Here  are  some  examples  of  legal 
property  descriptions: 

-  perf  ortn_f  etchmC  f  etchm_acti  vat«dtn.  qJ  )    ■> 

f etchm_comp 1 etedt v ] {  the  transition  "perf orm_f etchm" 
occurs  when  there  is  a  message  in  the  place 
"f etchm_acti vated" .  The  message  is  taken  from  the  place 
in  such  a  way  that  all  message  elements  (memaddr  m  and 
state  q)  are  available  to  the  transition.  Then  the  action 
of  getting  the  memory  contents  is  performed  and  the 
resulting  value  v  is  transmitted  as  a  message  to  the 
place  nf etchm_compl etedn 

-  perf orm_storer ( storer_acti vatedC v.  r . q 3 )  »> 
storer_completedCql ] ;  the  transition  "perf orm_storerM 
occurs  when  there  is  a  message  in  the  place 
"storer_acti vated"  in  such  a  way  that  the  message  is 
taken  from  the  place  in  such  a  way  that  its  message 
elements  (value  v,  regaddr  r  and  state  q)  are  available 
to  the  transition.  The  action  of   storing  the   value  v  in 
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register   r    is   performed   and   the   new   state   ql   is 
transmitted  as  a  message  to  the  place  "storer_corap 1 eted" 

Functionally,   the   internal   actions    performed   by 

transitions  follow   the  rules  stated  as  static  properties  for 

the  functions  involved. 

4.   Initial ization 

In  some  kinds  of  nets  we  have  an   internal  circuit  of 

places   in   order   to   act  as  a  synchronization  mechanism  (as 

illustrated  in  Figure  4.4  to  provide   mutual  exclusion).  They 

have  to   be  initiated  somehow  i.e.  a  message  has  to  be  placed 

in  at  least  one  of  these  places  since   they  are   not  provided 

with  messages  from  outside  the  net.  We  going  to  describe  this 

initialization  by  using  the  symbol  "=>"  used  to   indicate  the 

placement   of   a   message   into   a  place.  The  following  is  an 

example  of  an  initialization: 

«>  f  etchm_avai  1  C  ]  ;   the   place   **f etchm_avai  1  w   is  loaded 
with  an  empty  message 

The  initialization  of  a  place  is  a  one-time  action  at 

the  beginning  of   system   start   and   provides   the  necessary 

conditions     to   get   a   process   going.  It  can  be  viewed  as 

establishing  the  initial  state  of  a   computer  system   when  it 

is  turned  on. 
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V.   THE  ABSTRACT  PROCESSOR  TIMING  SPECIFICATION 

In  this  chapter  we  want  to  present  some  examples  on  how 
specific  problems  of  timing  in  computer  system  can  be  modeled 
using  the  methodology  in  a  top-down  fashion.  The  examples 
resemble  a  variety  of  computer  system  timing  problems  to  test 
the  use  of  Petri  Nets  in  specifying  the  timing  properties.  In 
Appendix  B  a  complete  specification  of  the  static  and  dynamic 
properties  of  a  reduced  Abstract  Processor  is  presented.  We 
have  chosen  to  use  the  Abstract  Processor  as  the  object  to  be 
specified  in  timing  considerations  because  of  the  following 
reasons : 

-  to  emphasis  this  work  as  the  logical  step  following  the 
work  of  specifying  static  properties  of  systems, 

-  by  specifying  a  non-existent,  abstracted  processor  we 
intentionally  leave  the  issue  of  the  actual 
implementation  untouched  since  we  stated  that  by  whatever 
means  the  specification  is  implemented  the  processor  will 
have  the  specified  properties, 

-  to  emphasize  our  intention  of  specifying  what  the  user  of 
a  processor  wants  to  achieve  and  not  how  it  is 
implemented  as  compared  to  a  traditional  processor  design 
approach  that  is  dominated  by  engineering  and 
implementation  issues. 

Also  we   want  to   show  how   well  our  methodology  can  deal 

with  the  special  aspects  of  timing   in  computer   systems.  The 

special  aspects   we  are   concerned  with  are  mutual  exclusion, 

interrupt  processing  and  concurrency.   Despite  the   fact  that 

the  Abstract   Processor  is  in  its  static  part   specified  as  a 

simple  single  processor  during   this   work   we   have  realized 
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that   even   there,   a   lot   of   potential   concurrency  can  be 
detected. 

Whenever  we  refer  to  actual  implementation  we  do  this 
with  the  intention  to  give  on*  example  of  how  the 
specification  could  be  realized.  Once  again  we  emphasize  that 
the  methodology  stated  in  this  work  is  only  concerned  with 
what  is  available  in  a  system  and  not  with  the  how  it  is 
implemented.  We  want  to  remind  the  reader  that  the 
methodology  developed  here  is  intended  to  be  general.  That 
is,  it  can  be  equally  applied  to  the  specification  of 
computer  resources  that  may  be  implemented  in  hardware, 
software  or  firmware.  With  this  in  mind  we  have  look  at  the 
timing  specification  not  as  a  blueprint  by  which  a  system  can 
be  build  directly  but  rather  as  formally  stated  requirements 
a  system  has  to  fullfil  no  matter  what  approach  is  chosen  for 
the  implementation  . 

A.   ATOMIC  NETS 

One  feature  of  the  methodology  is  it  forces  the  specifier 
to  focus  on  the  essential  nature  of  the  system  components. 
When  we  consider  these  essential  components  as  actions  in  a 
system  that  are  not  further  divisible  we  can  speak  of  atomic 
actions  which  we  want  to  specify  as  atomic  nets  in  our 
methodology.  Such  nets  will  use  no  other  net  in  their 
specification  and  so  can  be  considered  as  building  blocks  of 
a  system.  In  general  they  represent  the  elementary  actions  in 
a   system.   The   Abstract   Processor  consists  of  several  such 
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elementary  actions  and  to  illustrate  this  idea,  we  will  show 
how  the  actions  of  store  operations  and  fetch  operations  can 
be  described  with  atomic  nets. 

B.   MODELING  OF  MEMORY  AND  REGISTER  ACCESS  TIMING 

The  first  question  we  have  to  ask  when  we  want  to  specify 

the  access  of  memory  or  registers  is  what  kind  of  information 

do  we  have  to  have  available   to  perform   an  access   and  what 

information   we   obtain   after   the   access  has  been  made.  In 

order  to  perform  an  access  the  address  of  the  memory   cell  or 

register  has   to  be  available.  Depending  whether  a  store  or  a 

fetch  has  to  be  performed,  we  either  have  to  provide   a  value 

for  this  process  or  we  obtain  a  value  from  the  process.  Also, 

to  indicate  the  current   contents  of   the  register   or  memory 

cell  we   have  to  indicate  the  process  for  accessing  the  state 

of  the  processor.  In  case  of  a  store   access  we   obtain  a  new 

state   as   the   result   of   the  process  since  the  change  of  a 

memory  cell  or  register  also  changes  the  state. 

At  this  stage  we  have  established   the  components   of  any 

process  dealing   with  the   access  of   memory  or  registers.  We 

anticipate  that  accesses  to  memory  and  registers  will  be  made 

from  various   places  in   the  system,  so  we  provide  a  netlabel 

for  every  entry  and  exit  place.  In  terms  of  our  specification 

methodology  can   now  define   the  entry  and  exit  places  of  the 

subnet : 

-  the   fetching   of   the   contents   of   a   memory   cell   is 
requested   by   providing   message   which   consists  of  the 
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memory  address  and  the  state  to  the  following  entry- 
place:  req_fetcha>( net  label ) Cmemaddr. state] | 

-  We  obtain  as  a  result  a  corresponding  message  containing 
the  value  from  the  exit  place: 
avai  l__fetchm( net  label  )  C  val  3  ; 

-  similarly  we  state  the  entry  and  exit  places  for  fetching 
the  contents  of  a  register: 

req_fetchr (net label ) Cregaddr. state! ;  as  the  entry  place 
and  avai 1 _fetchr (net  label ) t val J ;  as  the  exit  place 

-  the  storing  of  a  value  into  a  memory  cell  is  requested  by 
providing  a  message  which  consists  of  the  value  to  be 
stored,  the  memory  address  and  the  state  to  the  following 
entry  place:  req__s  torem(  net  label )  C  val .  nemaddr.  state]  ; 

-  We  receive  as  a  result  a  corresponding  new  state  from  the 
exit  place:  avai I _storem( net  I abe 1 ) t s tate ] ; 

-  similarly  we  define  the  entry  and  exit  places  for  storing 
values  into  registers; 

req_storer (net  1 abe 1 ) C val . regaddr. state] ;  as  the  entry 
place  and  avai 1 _storer (net labe 1 ) [state] ;  as  the  exit 
place. 

To  show  the  versatility  of  the  proposed  methodology  we 
will  specify  memory  and  register  access  differently:  we  are 
going  to  specify  memory  access  in  a  way  that  allows  only  one 
access  to  one  memory  cell  at  a  time  (an  implementation  for 
this  method  might  be  a  single  memory  unit  allowing  only  one 
access  at  a  time).  On  the  other  hand  we  might  want  to  able  to 
access  registers  in  parallel.  These  requirements  determine 
the  internal  structure  of  resulting  specification. 

Considering  the  above  requirements  on  how  we  have  to 
specify  the  system  we  realize  that  we  have  to  construct  the 
specification  to  deal  with  memory  accesses  and  accesses  to 
each  register  separately. 
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As  the  next  step  we  are  going  to  specify  the  memory 
accesses.  Since  we  know  from  our  requirements  that  only  one 
access  at  a  time  is  allowed  to  the  memory  we  have  to  provide 
a  mutual  exclusion  mechanism  in  our  specification  that  makes 
sure  that  the  memory  is  not  accessed  by  more  than  one  request 
at  a  time. 

From   Figure   5.1   we   see   that  from  any  system  location 

indicated  by  a   netlabel   a   message   in   an   entry   place  to 

request   a   memory   access   can   only  trigger  a  transition  to 

activate  the  process  when   the   process   is   available.  Since 

there  is   only  one  empty  message  to  indicate  the  availability 

of  the  net  only   one  request   can  be   honored  at   a  time.  The 

availability  is   restored  when   the  access  is  completed.  Also 

we  see  that   the   internal   places   wprocessed_f or"   serve  as 

traffic  signs   to  direct   the  results  to  the  appropriate  exit 

places.  Drawing  the  picture  of  the  net  can  be  helpful   to  the 

process  of   specifying  net  just  as  flow  charts  can  be  helpful 

in  programming  tasks,  but  our  intention  is  primarily  to  state 

a  formal   specification.  The  following  is  the  dynamic  part  of 

the  memory  access  specification  expressed  in  precise  syntax: 

entry  places 

req_f  etchm(net labe 1 ) E memaddr. state] ; 
req_storem(net labe 1 ) C  val . memaddr . state] ; 

exit  places 

avai l_f  etchm( net  label ) C  va 1  ] ; 
avai l_s to rem (net  label )  E  state] ; 

internal  places 

access_avai IE]; 

f etchm_f  or (net  label ) E ] ; 

f etchm_acti vat edE memaddr. state] ; 
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f  etchm__completedt  val  ]  ; 
storem_f  or (net labe 1 )  [  3  ; 
storem_acti vatedC val . memaddr. state] ; 
storem_compl eted[ state] ; 

initial  state 

=  >  access_avai  1  C ]  ; 

transitions 

act_fetchm:  [memaddr. state], []  ->  C memaddr . state] , [ 3 ; 

perf orm_f  etchm:  [memaddr . state]  ->  (vail; 

f inish_fetchm:  CvaI3,M  ->  [val],[]j 

act_storem:  C val . memaddr. state] , [ ]  -> 

[val . memaddr. state],  C]; 

perf orm_storem:  C val . memaddr . state]  ->  [state]; 

f inish_storem:  [state], []  ->  [state], []; 

properties 

act_f  etchm( req_f etchm( 1 1 ) [m. q]  ,  access_avai 1 [ ] )  => 

f  etchm__f  or  (  1  1 )  [  ]  ,  f  etchm_act  i  vatedtm.  q]  ; 
perf orm_f etchm ( f etchm_acti vatedtm. q] )  => 

f etchm_compl etedC v] ; 
f inish_f etchm(f etch_completed[v] ,  f etchm_f  or ( 1 1 ) [  ]  )  => 

avai  l__f  etchm (  1 1 )  [  v] ,  access_avai  1  [  ]  ; 
act__storem(req_storem(  1 1 )  [  v.  m.  q] ,  access_avai  1  [  ] )  => 

storem_f or ( 1 1 ) [ ] ,  storem_act i vatedC v. m. q] ; 
perf orm_storem( storem_acti vated[ v. m. q] )  => 

storem_compl e ted [ ql ] ; 
f inish__storem(storem_compl etedCql ]  ,  storem__f  or  (  1  1  >  [  ]  )  => 

avai l_storem( 11) [ql],  access_avai 1 [ ] ; 

When  we  look  at  the  requirements  of  the  register  accesses 
we  see  that  the  above  design  for  memory  accesses  is  not 
suitable  for  register  access  if  we  want  to  allow  for 
concurrent  access  to  registers.  So  we  have  to  find  a  way  to 
express  the  properties  of  register  accesses.  Looking  closely 
again  at  the  requirements  we  realize  that  each  register  has 
the  same  access  policies  as  the  whole  memory  we  specified 
before.  This  leads  us  to  the  fact  that  every  register  has  to 
have  its  own  specification.  For  the  sake  of  simplicity  let  us 
say  that  our  system  has  three  registers  with  register 
addresses  1,2  and  3.  We  could  now  define  three  different  nets 
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each  for  the  access  of  a  certain  register.  There  is  one 
problem  though:  whenever  a  register  access  is  requested  from 
somewhere  in  the  system,  the  proper  net  for  the  register  to 
be  accessed  has  to  be  addressed.  So  we  want  to  have  the 
decision  about  which  register  net  is  meant  centralized  in  one 
place   in   the   system.   Therefore   we   employ   some  decision 


accesa_avail [ ] 


> 


raq_f etchn 

(natlabel 

[mamaddr .  statje  J 


o 


f at chm_ activated 
[mamaddr. state] 


o 


f atchm_completad 
[val] 


perfonn_fatchm 

—6— 


fetchm  for (natlabel) [] 


a<rt    fatchm 


finish   fat 


req_storem 

(natlabal) 

[val .mamaddr 

. at at a] 


o 


storam_activated 
[val .mamaddr 
.stata] 


o 


storam_com,->latad 
[stata] 


parform_storam 

-K3— 


storam  for (natlabal) [] 


+© 


avail_f atchra 

(natlabal) 

[val] 


:hm 


+© 


avail_storem 

(natlabel) 

[state] 


act    storam 


finish  storem 
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mechanism    to    select    the    right    register    access    net.     In    this 
case       the       graph      drawn      out       in      Figure    5.2    of    the    net    might 
confuse    more    than    it       helps.     We       try    to       specify    the    register 
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Figure    5.2:    Petri    Net    Graph    for    Register    Access 
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access  just   by  direct   reasoning.  Still,  the  graph  in  Figure 

5.2  illustrates  that,  despite  the  fact  that  each  register  can 

be   accessed   independently   from   the   other  registers,  only 

oneaccess  to  a  register  is  allowed  at  a   time  because   of  the 

separate   "access_avaiIB   places   for   each   register.   These 

places   prohibit   any   access   to   a   register   until   it   is 

avai labl e. 

Again,  we  can  anticipate  that  access  to  registers  will  be 

requested  by  several  locations  in  the  system.  So  we  can  state 

the  entry   and  exit   places  as  we  have  in  the  memory  example. 

Next   we   already   found   out   that   there   three  independent 

register  access   nets  and  we  can  use  again  this  structure  for 

internal  places  and  transitions  we  used  in  the   memory  access 

net.  But   how  do  we  state  that  the  net  for  register  1  is  used 

when  there  is  an  access  request  for  register  1  and   only  this 

net?  The   indication  that   a  certain   register  is  going  to  be 

accessed  is  the  register   address   contained   in   the  request 

message.  Now   instead  of   a  name   of  the   register  address  we 

state  the  actual  value  of  it  when  we  specify  the  properties: 

entry  places 

req_f  etchr (net labe 1 ) C  regaddr . state] ; 
req_storer (net labe 1 ) [ va 1 . regaddr. state ] ; 

exit  places 

avai l_f etchr (net labe 1 )[ val ] ; 
avai l_storer(net label )[ state] ; 

internal  places 

accessl_avai 1 [ ] ; 

fetchrl_activatedC  regaddr.  state] ; 
f etchr l_compl etedCval ] ; 
storerl_activatedCval . regaddr . state] ; 
s torerl_comp letedCstate] ; 
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access2_avai 1 C ] ; 

f etch r2_acti va ted C regaddr.  state] ; 

f etchr2_completed[ val ] ; 

storer2_act i vatedC va 1 . regaddr. state] ; 

storer2_compl etedC state] ; 

access3_avai 1 C ] ; 

f etchr3_acti va ted C regaddr . state] ; 

f  etchr3__completed[  val  ]  ; 

storer3__acti vatedC val .  regaddr.  state]  ; 

s tor er3_comple ted [state] ; 

f etchr_f  or (net  label ) C ] ; 
storer__f  or  (net  label  )  C  ]  ; 

initial  state 

=>  accessl_avai 1 C ] ; 
=>  access2_avai 1 C ] ; 
=>  access3_avai 1 C ] ; 

transi  tions 

act_fetchrl:  [ regaddr . state] , C ]  ->  [regaddr . state] , C ] ; 

perf orm_f etchr 1 :  C regaddr . state]  ->  [val]; 

f inish_fetchrl:  [val],[]  ->  Cval3,C3; 

act_storerl:  [va 1 . regaddr. state] , [ ]  -> 

[ val . regaddr. state], CD; 

perf orra_storerl :  [val . regaddr . state]  ->  [state]; 

f  inish_storerl :  [state], []  ->  Estate], M; 

act_fetchr2:  [regaddr . state] ,[ ]  ->  [ regaddr . state] ,[] ; 

perf orm_f etchr2:  [ regaddr . state]  ->  [val]; 

f inish_fetchr2:  [val],[]  ->  [val],[]; 

act_storer2:  [ val . regaddr . state] ,[ ]  -> 

[ val . regaddr. state] , [ ] ; 

perf orm_storer2:  [va 1 . regaddr . state ]  ->  [state]; 

f  inish__storer2:  [state],  []  ->  [state],  M; 

act_fetchr3:  [ regaddr. state] ,[ ]  ->  [ regaddr . state] ,[]  ; 

perf orm_f etchr3:  [ regaddr . state ]  ->  [val]; 

f inish_fetchr3:  [val],[]  ->  [val],[]; 

act_storer3:  [ va 1 . regaddr . state] ,[ ]  -> 

[val . regaddr. state] ,[] ; 

perf orm_storer3:  [ val . regaddr . state ]  ->  [state]; 

f inish_storer3:  [state], []  ->  [state], []; 

properties 

act_f etchrl (req_f etchr ( 1 1 )[ 1 . q] ,  access l_avai 1 [] )  => 

f etchr_f or ( 1 1) [ ] , f etchr l_aotiva ted [ 1. q] ; 
perf orro_f etchr 1 ( f etchr l_activated[ 1 .  q] )  => 

f etchr l_compl e tedt  v ] ; 
f inish_fetchrl(fetchl_completed[v],  f etchr_f or ( 1 1 ) [ ] )  => 

avai l_f  etchr ( 1 1 ) [ v] ,  accessl_avai 1 [ ] ; 
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act_storerl < req_storer ( 1 1 ) C v. 1 . q] ,  access l_avai 1 C 3 )  => 
storer_for ( 1 1 ) C  3 ,  storerl_acti vatedC  v  .  1 , q  3 ; 

per f orm_s tore rl ( storerl_acti vatedC v.  1.  q] )  => 
storerl_compl etedCql 3 ; 

f inish_storer 1 ( storerl_completedCql 3,  storer_for(ll)C3) 
=>  avai l_storer < 1 1 ) Cql 3 ,  access l_avai 1 [ 3 ; 

act_f  etchr2(req_f  etchr ( 1 1 ) C2. q3 ,  access2_avai 1 C 3 )  => 

fetchr_f  or ( 1 1)  C  3  , f etchr2_acti vatedC2.  q3 ; 
perf orm_f  etchr2( f etchr2_act i vatedC 2.  q3 )  => 

f etchr 2_compl etedC v3 ; 
f inish_f etchr2(f etch2_compl etedC v3 ,  f etchr_f or ( 1 1 ) C 3 )  => 

avai 1 _f etchr ( 11) [ v  3 ,  access2_avai 1 [ 3 ; 
act_storer2(req_storer < 1 1 ) C v. 2. q3 ,  access2_avai 1 C 3 )  => 

storer_for(ll)C3,  storer2_acti vatedC v.  2.  ql ; 
perf orm_s tor er2( storer2_acti vatedC v. 2. q3 )  s> 

storer2_compl eted [ ql 3 ; 
f  inish_storer2( storer2_corapl eted Cql 3,  storer_for(ll)Cl) 

=  >  avai l_storer (  1  1 ) Cql 3  ,  access2_avai 1 C ] ; 

act_fetchr3( req_f etchr ( 1 1 ) C3. q3 ,  access3_avai 1 C 3 )  => 

f etchr _f or ( 1 1 ) C  3  ,  f etchr 3_acti vatedC 3.  q3 ; 
perf  orm__f  etchr3(  f  etch r3_acti  vatedC 3.  q3  )  => 

f etchr 3_compl etedC v  3 ; 
f inish_f etchr3(fetch3_completedCv3 ,  f etchr_f  or ( 1 1 ) C 3 )  => 

avai l_f etchr ( 1 1 ) C v3  ,    access3_avai 1 C  3 ; 
act_storer3( req_storer ( 1 1 ) C v. 3. q3 ,  access3_avai 1 C 3 )  => 

storer_for( 11)C3,  storer3_acti vatedC v. 3. q3 ; 
perf orm_s tor er3( s t or er3_acti vatedC v.  3.  q3 )  «> 

storer3_compl eted [ ql 3 ; 
f  inish_storer3(storer3_compl eted Cql 3,  storer_for(ll)C3) 

=  >  avai l_storer ( 1 1 ) Cql 3  ,  access3_avai 1 C 3 ; 

We  see  that  even  specifications  of  simple  resources 
become  large  and  complex  and  the  drawing  the  net  is  even  more 
complex.  Here  we  realize  the  real  benefit  of  the  introduction 
of  subnets:  once  these  subnets  are  specified  we  can  use  their 
properties  everywhere  in  our  system  simply  by  stating  the 
entry  and  exit  places  of  the  subnets  in  the  net  we  want  to 
specify.  Those  nets  using  subnets  are  actually  extensions  of 
the  subnets.  The  next  section  will  illustrate  these  facts  in 
detai 1 . 
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C.   MODELING  OF  INSTRUCTION  FETCH  AND  EXECUTION  TIMING 

From  the  static  specification  of  the  Abstract  Processor 
we  see  that  there  are  two  operands  "prog"  and  "exq"  which  are 
responsible  for  the  process  of  executing  programs.  The 
process  is  kept  going  by  corecursive  calls  between  those  two 
operators. 

Even  though  those  two  processes  are  very  closely 
connected  by  corecursive  calls  we  want  to  consider  them 
separately  and  start  with  specifying  the  "exq"  process. 

The  **exqH  process  needs  information  about  the  instruction 
to  be  executed,  the  current  memory  address,  and  the  state  of 
the  processor.  After  the  process  has  finished  it  returns  the 
new  state.  This  determines  the  contents  of  the  messages  the 
entry  and  exit  places  of  this  net  have  to  accommodate.  Still 
we  have  to  decide  what  kind  of  execution  unit  we  want  to 
specify.  We  want  to  specify  that  only  one  execution  unit  can 
be  performed  at  a  time.  This  means  that  we  have  to  provide 
mutual  exclusion  for  the  use  of  this  net.  We  can  do  this  the 
same  way  as  we  provided  for  memory  accesses.  We  can 
accomplish  that  by  providing  a  distinct  entry  place  and  exit 
place  indicated  by  netlabels.  Now  we  are  in  a  position  to 
specify  the  entry  and  exit  places: 

-  req_exq(net label ) t instr. memaddr. state] j    as    the   entry 
place 

-  aval l_exq(net label ) [memaddr. state] j  as  the  exit  place 

At  this  point  we  have  to  look  closely  at  the  actions  an 
execution  on  an  instruction   has  to   accomplish:  retrieval  of 
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information  from  the  instruction,  about  register  and  memory 
addresses  of  operands,  and  about  the  operation  to  be 
performed,  accesses  to  the  operands,  application  of  the 
operator,  and  calculation  of  the  address  of  the  next 
instruction  to  execute.  We  see  now  that  the  previous 
specifications  for  memory  and  register  accesses  will  come  in 
handy  when  have  to  specify  these  accesses  in  the 
specification.  Also  we  assume  for  this  specification  that 
there  are  nets  for  the  retrieval  of  operands  and  operators 
from  the  instruction,  the  application  of  operands  and 
calculation  of  the  next  memory  address. 

The  next  issue  we  have  to  address  is  the  fact  that 
different  instructions  have  to  be  executed  differently.  Here 
a  decision  mechanism  similar  to  the  one  we  introduced  to 
access  a  specific  register  can  help  us  to  make  the 
specification  structured  and  understandable.  The  mechanism  we 
introduce  here  has  to  recognize  from  the  instruction  part  of 
the  message  which  execution  is  requested  and  has  to  direct 
the  path  within  the  specification  to  the  appropriate  part  of 
the  specification.  In  the  formal  specification  we  indicate 
this  explicitly  by  the  contents  of  the  instruction  part  of 
the  request  message. 

In  the  following  we  show  some  representative  examples  of 
the  execution  specifications  of  different  instructions.  Their 
graphs   are   depicted   in   Figures  5.4  and  5.5  and  illustrate 
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clearly  the  simplification  obtained  by  the   use  of  predefined 

subnets. 

entry  places 

req_exq( net  label ) C  instr . memaddr.  state] ; 

exit  places 

avai l_exq(net labe 1 ) [memaddr. state] ; 

internal  places 
exq_avai 1 C ]  ; 
exq_f  or (net  label  ) C  ]  ; 

exq_monad_activated Estate 3 ; 
exq__monad_f  etchC state]  j 
exq_monad_apply [ state] ; 
exq_monad__storeC  ]  ; 

ex q_mo v_r_r _ac t i vat edC state] ; 
exq_mov_r_r_perf ormCstate] ; 
exq_mov_r_r_storeC  ]  ; 

initial  state 

s>    exq_avai 1 C ] ; 

transitions 

acti vate_exq_monad :  C instr . memaddr . state] , C ]  -> 

Cstate] ,  Cinstr  3 ,  [instr  3 , [instr], [memaddr] ; 
start_exq_raonad:  [ s tate 3 , [ regaddr 3 ,  -> 

[state] , [ regaddr. state] ; 
apply_exq_monad :  [ state  3 , [operator  1,1 va 1 ]  -> 

[state] , [operator. va 1 3 ; 
store_exq_monad :  [ s tate 3 ,  [ va 1 3  ,  [ regaddr 3  -> 

[ 3 , [ va 1 . regaddr. state] ; 
f  inish_exq__monad  :  [],  [state] ,  [memaddr  ]  -> 

[memaddr. state] ; 

acti vate_exq_mov_r_r :  [ instr  .  memaddr  .  state  3  ,  L 3  -> 

[state], [instr], [instr], [memaddr  3 ; 
start_exq_mov_r_r :  [start ],[ regaddr ]  -> 

[state] , [ regaddr. state] ; 
store_exq_mov_r_r :  [state] ,[ regaddr ],[ val ]  -> 

[  ] , [ val . regaddr. state] ; 
f  inish_exq_mov_r__r  :  [],  [state]  ,  [memaddr  ]  -> 

[memaddr. state] ; 

properties 

acti vat e_exq_monad (exq_avai 1 [ ] , 

req_exq( 1 ) [monad ( o. rl.r2).m.q]>  => 
exq_f or (!)[],  exq_monad_act i vated[ q] , 
req_operator (11) [monad (o. rl . r2) 3 , 
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req_operandl (12) C monad (o. rl. r2) ] , 

req_pperand2< 13) C monad (o. rl.r2)l, 

req_nextmemaddr( 14) Cm] ; 
start_exq_monad (exqjnonad_acti vatedCq] , 

avai l_operandl ( 1 1 ) Crl 3 )  ->  exq_monad_f etchCq] , 

req_f  etchr (  I  5 ) C  r 1 . q] ; 
apply_exq_monad(exq_monad_f etchCq] ,  avai l_f  etchr ( 1 5 ) C  v ] , 

avai l_operator ( 1 1 ) Co] )  =>  exq_monad_applyCq3 , 

req_apply_mop( 16) Co.  v] ; 
store_exq_monad (exq_monad_applyCq3 , 

avai  l_apply_mop(  16)  C  vl  3 ,  avai  l__operand2(  13)  C  r23  )  => 

exq_monad_8tore[ 3 ,     req_storer  <17)Cvl.r2.q3; 
f inish_exq_monad (exq_monad_storeC  3 ,  avai l_storer( 17) Cql 3 , 

avai  l__nextmemaddr  (  14)  Cml  3  )  ■>  avai  1  _exq(  1  )  Cml .  ql  3  ; 

act  i  vate_exq_mov_r__r  (exq_avai  1  C  3  , 

req_exq( 1 ) Cmov_r_r (rltr2).m.q3)  => 

exq_mov_r_r_acti vatedCq] , 

req_operandl  (11)  Cmov__r__r  (  rl ,  r2)  ] , 

req_operand2( 12) Cmov_r_r ( rl,  r2) 3  , 

req_nextmemaddr ( 13) Cm  3 ; 
start_exq__mov_r_r  (exq_mov__r__r_act  i  vatedCq  3 , 

avai l_operandl ( 1 1 ) Crl 3 )  => 

exq_mov__r_r__perf  ormCq] ,  req_f  etchr  (  14)Crl.q3; 
store_exq_mov_r_r  ( exq_mov_r__r_perf  ormC q 3  , 

avai l_f  etchr( 14) C v3 ,  avai 1 _operand2( 12) C r23 )  => 

exq_mov_r_r_storeC  3 ,  req_storer  C v. r2. q3 ; 
f  inish_exq_raov_r_r (exq_mov_r_r_storeC  3 ,  avai l_storer  Cql 3 , 

avai l_nextmemaddr ( 13) Cml 3 )  => 

avai l_exq(l)Cml.ql3j 

The  above  two  examples  show  the  specification  of  the 
execution  of  a  monadic  instruction  and  of  a  move  instruction. 
We  have  used  the  previously  specified  register  access 
(nfetchrM  and  "storer")  to  fetch  the  contents  of  a  register 
and  to  store  a  value  into  a  register.  The  way  we  used  them 
was  that  we  stated  their  entry  and  exit  places  at  the 
appropriate  locations  in  the  description  of  the  properties  of 
our  execution  specification.  In  the  same  way  we  invoked  the 
specifications  of  wnextraemaddrM,  "apply_mop,t ,  "operandi", 
"operand2"  and  "operator"  which  for  this  example  we  assumed 
to  be  defined  . 
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We  want  to  emphasize  at  this  point  that  the  stated 
properties  of  the  given  examples  are  not  the  only  way  the 
execution  could  be  specified:  we  are  following  the  philosophy 
that  as  soon  as  the  information  is  available,  the  possible 
requests  are  made  based  on  the  information.  In  a  real 
specification  other  considerations  may  have  priority,  but  our 
intention  is  to  show  how  this  can  be  accomplished  using  the 
methodology. 

The  next  part  of  the  specification  is  to  state  the  "prog" 
part  and  to  connect  it  with  "exq"  in  a  way  that  illustrates 
the  corecursi veness  of  their  interconnection.  Since  we  have 
already  modeled  the  "exqn  part  as  a  process  taking  an 
instruction,  a  memory  address  and  the  state,  and  provides  a 
new  memory  address  and  a  new  state,  we  want  this  as  a  subnet 
in  our  "prog"  specification.  When  we  look  again  at  the  static 
specification  of  "prog"  of  the  Abstract  Processor  we  realize 
that  this  process  needs  a  memory  address  and  the  state  to  get 
started,  i.e.  the  same  information  as  "exq"  provides  as 
output.  This  fact  leads  to  the  idea  of  a  loop  in  requesting 
"prog":  when  "prog"  has  performed  its  initial  tasks  and  has 
invoked  "exq"  it  is  in  the  situation  of  requesting  itself 
again  as  soon  as  the  result  of  "exq"  is  obtained.  This  idea 
will  work  nicely  once  the  process  is  started,  but  how  do  we 
get  this  process  running?  Here  we  can  claim  that  the  initial 
request  has  to  come  from  the  outside  world  (imagine  a 
possible  implementation  as  an  on-switch  at  the  machine  which 
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Figure  5.3:  Partial  Petri  Net  Graph  of  nexq_monad-rt 


62 


Figure  5.4:  Partial  Petri  Net  Graph  of 


"  e  x  q  _m  ov_r_r" 
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resets  the  state  and  sets  the  program  counter  to  a  predefined 

initial  value).  Ue  want  to  specify   this  process   as  a  single 

control   unit   and   that   this   is   the   major  process  in  the 

system.  The  following  is   a  possible   specification  of  "prog" 

(see  also  Figure  5.5): 

entry  places 

req_progCmemaddr . state] ; 

internal  places 
prog_avai 1 C  ] ; 

prog_f  etch Cmemaddr. state] ; 
prog_instr  Cmemaddr . state] ; 
prog_perf ormC ] 

initial  state 

=>  prog_avai 1 [ ] ; 

transi  t ions 

acti vate_prog:  C ], Cmemaddr . state]  -> 

Cmemaddr. state], Cmemaddr . state] ; 
get_instr_prog :  Cmemaddr . state] , C va 1 ]  -> 

Cmemaddr . state ] , C  va 1 ] ; 
perf orm_prog :  Cmemaddr . state] , C instr ]  -> 

C ] , C  instr. memaddr . state] ; 
f  inish_jprog  :  C  ],  Cmemaddr  .  state]  -> 

C ] , Cmemaddr. state] ; 

properties 

acti vate_prog (prog_avai 1 C ] ,  req_progCm. q] )  => 

prog_f  etchCm. q] ,  req_f  etchra( 1 1 ) Cm. q] ; 
get_instr_prog (prog_activatedCm.q]f  avail_fetchro( 1 1 ) C v] ) 

=>  prog_instr Cm. q] ,  req_atomof instr ( 12) Cv ] ; 
perf ormjprog (prog_instrCm.q], 

avai 1 _atomof instr ( 1 2) C i ] )  => 

prog_perf ormC ] ,  req_exq( 13) C  i . m.  q] ; 
f ini sh_prog (prog_perf ormC ]  ,  avai l_exqCml . ql ] )  => 

prog_avai 1 C ] ,  req_progCml . ql ] ; 

The  declaration  of  nreq_prog"  as  an  entry  place  models 
our  previous  stated  connection  to  the  outside  world.  Note 
that  this  specification  in  the  form  presented  could  not  be 
used  as  a  subnet  since  no  exit  place   has  been   declared.  The 
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following  Figure  5.5  shows  how  this  specification  is  drawn  as 
a  net. 

D.   MODELING  OF  INTERRUPTS 

The  above  specifications  of  "exq"  and  "prog"  and  their 
interconnection  in  their  current  form  does  not  provide  for 
any  recognition  and  processing  of  interrupts.  This  chapter  is 
to  show  one  way  how  interrupts  oould  be  handled  using  our 
specification  methodology. 

As  always  the  first  step  is  to  state  the  requirements  for 
the  process  of  interrupt  handling.  We  want  to  look  at 
interrupts  as  a  signal  which  comes  either  from  outside  or 
inside  the  system  on  which  the  current  running  program  is 
interrupted  and  a  handler  program  at  a  predefined  location  is 
started.  After  the  completion  of  the  handler  the  execution  of 
the  interrupted  program  is  resumed,  therefore  we  need  to  save 
the  memory  address  of  the  interrupted  program.  Also  we  want 
the  invocation  of  the  interrupt  handler  only  to  happen  at  a 
defined  state,  i.e.  between  the  completion  of  the  execution 
of  one  instruction  and  the  fetching  of  the  next  instruction. 
Another  requirement  is  that  the  interrupt  handler  acts  on  a 
single  interrupt  only  one  time,  so  that  a  following  interrupt 
signal  can  be  interpreted  as  another  interrupt.  In  the 
following  specification  we  assume  that  there  is  a  dedicated 
stack  in  the  system  on  which  the  current  memory  address  of 
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Figure  5.5:  Graph  of  "prog"  without  Interrupt  Handling 
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the  running  program  can  be  saved.  Also,  for  simplicity 
reasons  we  allow  only  one  type  of  interrupt,  i.e.  the  handler 
has  to  determine  the  source  of  the  interrupt  by  software.  The 
following  is  one  way  to  specify  the  above  requirements  (also 
see  Figure  5.6) : 

entry  places 

req_prog C memaddr . state] ; 

internal  places 
prog_avai I C  3  ; 

prog_f  etchCmemaddr . state] ; 
prog_instr Cmemaddr  . state] ; 
prog_perf ormC ] 
prog__check Cmemaddr.  state] ; 
prog_saveC ] ; 

initial  state 

=  >  prog_avai 1 C ]  ; 

transitions 

acti vate_prog:  C ] , Cmemaddr . state]  -> 

Cmemaddr. state] ,  Cmemaddr. state] ; 
get_instr_prog:  Cmemaddr . state] , Cval ]  -> 

Cmemaddr. state] , Cval ] ; 
perf orm_prog:  C memaddr . state  3 ,  C ins tr ]  -> 

C  ] , C instr .memaddr . state] ; 
finish_prog:  C ], Cmemaddr . state]  -> 

Cmemaddr.  state],  M; 

normal_prog:  Cmemaddr . state] , C ]  -> 

C  ] , Cmemaddr . state] ; 
itrpt_prog : Cmemaddr ,  state] ,  C ]  -> 

C  ] , C  instr . memaddr. state] ; 
f in_int_prog:  C ], Cmemaddr . state]  -> 

C  ] , Cmemaddr. state] ; 

properties 

acti  vate_prog  (prog_avai  1  C  ]  ,  req__progCra.  q]  )  => 

prog_f etchCm. q]  ,  req_f etchm( 1 1 ) Cmemaddr. state] ; 
get_instr_prog(prog_acti vatedCm. q] ,  avai 1  _f  etchm( 1 1 ) C v] ) 

s>  prog_instr Cm.  q]  ,  req_atomof instr ( 12) Cv] ; 
perf orm_prog(prog_instr Cm. q] , 

avai l_atomof instr ( 12) C i ] )  => 

prog_jperf  ormC  ]  ,  req_exq(  13)  C  i  .  m.  q]  ; 
f inish_prog(prog_perf ormC ] ,  avai 1 _exqCml . ql ] )  => 

prog_checkCml .  ql ]  ,  req_checkC]; 
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norma l_prog ( prog_check C mi  .  ql 3  ,  avai 1  _normal C 3 )  => 

prog_avai 1 C ] ,  req_prog Crai . ql ] 
i trpt_prog(prog_checktml . ql ] ,  avai 1  _intrpt C 3 )  *> 

prog_saveC  3 ,    req_exqt  jsr( int_addr ,  sys_stk) .  ml.  ql 3 ; 
f in_int_prog(prog_saveC 3 ,  avai l_exqCm2. q23 )  *> 

prog_avai 1 C 3 ,  req_progCm2. q2  3 ; 


The  above  interrupt-sensiti ve  specification  of  wprogw  is 
very  similar  to  the  former  specification  of  "prog"  which  did 
not  provide  for  interrupt  handling  (compare  Figure  5.5  and 
Figure  5.6).  The  major  difference  is  that  an  "external  agent" 
is  invoked  as  soon  as  the  execution  of  the  instruction  is 
completed.  This  Agent  sends  a  message  to  one  of  its  output 
places  to  show  that  either  an  interrupt  is  present  or  not. 
This  construct  ensures  two  properties:  first,  the  External 
Agent  is  responsible  for  clearing  the  interrupt  signal  after 
it  has  recognized  it  so  that  an  interrupt  is  only  honored 
once;  second,  the  presence  of  an  interrupt  has  priority  over 
the  normal  way  of  execution  of  a  program.  Once  an  interrupt 
has  been  detected  by  the  Agent  and  its  appropriate  output 
place  has  been  provided  with  a  message  the  "prog"  process  can 
continue  and  it  will  place  the  current  memory  address  on  a 
specified  system  stack  by  executing  a  "push"  instruction  and 
will  start  a  new  cycle  at  the  system  interrupt  handler 
address.  Since  the  interrupt  handler  is  by  itself  a  loaded 
user  program  is  responsible  for  saving  the  necessary  register 
contents  and  for  restoring  those  registers  and  the  saved 
memory  address  from  the  system  stack  when  it  finishes. 
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Figure  5.6:  Graph  of  "prog"  with  Interrupt  Handling 
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E.   EXECUTION  OF  PROGRAMS 

The  question   to  be   asked  now   is:  how  will  the  proposed 

specification  methodology  show  the  timing  of  the  execution  of 

programs?  As  an  example,  let  us  consider  the  following  simple 

program: 

1000:  1 

1001 :  2 

2000:  M0V_M__R  1000,  rl 

2001:  M0V_M_R  1001, r2 

2002:  ADD  rl,r2,r3 

2003:  M0V_R_M  r3, 1002 

2004:  STOP 

The  above  program  retrieves  the  values   "1"  and   "2"  from 

memory  addresses   1000  and  1002  into  registers  "rl"  and  "r2w, 

adds  them  together,  with  the  result   in  "r3n,   and  than  moves 

this  result  into  memory  address  1002.  At  the  top  level  of  the 

specification  there  is  the  "prog"  net.  With  the  start  of  this 

program  it  receives  the  "req_progC2000. ql ] "4  message  from  the 

outside.  It  retrieves   the   instruction   contained   in  memory 

address   2000   and   invokes   the   "exq"   net  with  the  message 

"req_exqC instr . 2000. ql ] ".  Inside  the  "exq"   net  the  "external 

agent"   determines    the   appropriate    net   to   process   the 

instruction,  here  the  "mov_m_r"   net,   and   enters   this  net. 

After  the  completion  of  "exq",  "prog"  finishes  with  a  message 

"req_progt2001. q23"  to   itself  where   the  "2001"   and  q2  were 

obtained  from   the  execution   of  "exq".   At  this  point  "prog" 

starts   all   over   again    and   finishes    with   the   message 

"req_progt2002. q33".    This     repeats    until    the    "stop" 


4Netlabels  are  omitted  for  simplicity 
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instruction  is  executed  and   results   in   termination   of  the 

process.  Inside   the  invocations   of  the   "exq"  net  there  are 

several  uses  of  the   nets  to   access  memory   and  registers  as 

wel 1  as  to  process  "nextmemaddr". 

The   following    shows   the   major   messages   with   their 

included  data  that  are  exchanged   during   the   course   of  the 

execution   of   the   program   (not  necessarily  in  the  order  as 

they  might  occur): 

req_progC2000, ql ] 

req_f etchmC2000, ql ] 
avail _fetchmCnM0V_M_R  1000, rln 3 
req_atomof instr C "M0V_M_R  1000, rlw3 
avai  l_atomof  instr  Croov__m_r  ( 1000,  rl )  3 
req_exqCmov_m_r ( 1000, rl) .2000. ql3 

req__operandl  Cmov_m_r  ( 1000,  r  1 )  3 

avai  l__operand2C  1000  3 

req_pperand2Cmov_m_r ( 1000,  rl ) 3 

avai l_operand2Cr 1 3 

req_f  etchmC 1000. ql 3 

avai l_f etchmC 1 3 

req_storer C 1 . rl . ql 3 

avai l_storerCq23 

req_nextmemaddr C20003 

avai l_nextmemaddr C2001 3 
avai l_exqC2001. q2  3 
req_progC2001, q2  3 

req_f etchmC 2001 , q23 
avai l_f etchmC "MO V_M_R  1001, r2w 3 
req_atomof instr CwM0V_M_R  1001, r2n3 
avai l_atomof  instr C mo v_m_r (1001, r2) 3 
req_exqCmov_m_r (1001,  r2) . 2001. q23 

req_operandl Cmov_m_r ( 1001 ,  r2) 3 

avai l__operand2C 1001 3 

req_pperand2Cmov_m_r ( 1001 , r2) 3 

avai l_operand2C  r2  3 

req_f  etchmC 1001. q23 

avai 1 _f etchmC 2  3 

req_storer C2.  r2.  q2  3 

avai l_storerCq3  3 

req_nex tmemaddr C2001 3 

avai l_nextmemaddrC20023 
avai l_exqC2002.  q33 
req_progC2002. q3  3 

req_f etchmC2002, q33 
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avai  l_fetchn»[  "ADD  rl,r2,r3"3 
req__atomof  instr["ADD  rl,r2,r3**3 
avai 1 _a torn of instrCdyadr (add, rl, r2, r3) 3 
req_exq[ dyad (add, rl,  r2,  r3) . 2002. q3) 

req_operandl C dyad (add, rl,r2,r3)3 

avai 1 ^operandi [  r 1 ] 

req_operand2[ dyad (add, rl , r2, r3) 3 

avai 1 _operandl C  r2  3 

req_operand3C dyad (add, rl , r2, r3) 3 

avai l_pperand3Crl 3 

req_operator [ dyad (add, rl , r2, r3) 3 

avai l_operator Cadd3 

req_f  etchr Crl. q3  3 

avai  l__f  etchr£13 

req_f  etchrC  r2. q33 

avai l_f  etchrE23 

req_applydopCadd. 1.23 

avai l_apply_dopC3  3 

req_storerC3. r3. q3  3 

avai l_storer[q43 

req_nextmemaddr [2002  3 

avai l_nextmemaddr [2003  3 
avai l_exqC2003. q43 
req_prog[2003, q4  3 

req_f  etchmC2003, q43 
avail_fetchm["M0V_R_M  r3,1003w] 
req_atomof instrC wM0V_r_m  r3, 1003" 3 
avai l_atoraof  instr Cmov_r_m( r3,  1003) 3 
req_exqCmov_r_m(r3, 1003) .2003. q43 

req_operandl Cmov_r_m( r3, 1003) 3 

avai l_operand2C r33 

req_operand2Craov_r_m( r3, 1003) 3 

avai l_operand2C 10033 

req_f  etchr C  r3. q4  3 

avai I_f  etchmC33 

req_storerC3. 1003. q4  3 

avai l_storerCq53 

req_nextmemaddr [20033 

avai 1 _nex tmemaddr [2004 ] 
avai l_exq[2004.q5  3 
req_prog[2004.  q5 3 

req_f  etchmC2004, q53 
avai  l_fetchmC,tST0P,t3 
req_atomof instr ["STOP M 3 
avai l_atomof  instr[stop3 
req_exq[stop. 2003.  q4  3 
avai l_exq[  .  q43 
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With  the  appropriate  tools  to  track  certain  messages  and 
their  contents  one  is  able  to  take  snapshots  during  the 
course  of  the  execution  to  determine  the  timing  within  the 
execution. 
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VI .  SUMMARY  AND  CONCLUSION 

The  intention  of  this  work  has  been  to  present  a 
methodology  to  specify  timing  in  computer  systems  with  strong 
emphasis  on  the  issues  of  portability  and  reusability.  The 
work  has  been  also  influenced  by  the  goal  to  pursue  a 
practical  viewpoint  for  dealing  with  computer  resources.  In 
describing  the  essential  properties  of  timing  between 
abstracted  computer  resources,  it  has  been  possible  to  state 
the  required  timing  in  a  system  in  an  exact  and  rigorous  way. 
As  a  first  result  of  this  work  it  has  been  pointed  out  that 
the  attempt  to  specify  the  time  behavior  of  a  computer  system 
without  having  a  formal  specification  of  the  static  behavior 
of  the  system  will  lead  to  inconsistencies  and  errors.  We 
view  the  timing  specification  as  an  extension  of  the  static 
specification  (the  system  functionally)  to  a  complete 
specification  (the  system  functionally  and  dynamically). 

A.   ADVANTAGES 

This  methodology  is  based  on  Petri  Nets  and  their 
underlying  theory.  Since  Petri  Nets  are  an  accepted  and 
commonly  used  tool  in  a  variety  of  applications  one  familiar 
with  Petri  Nets  will  have  almost  no  problems  understanding 
the  methodology.  During  the  course  of  this  research  a  number 
of  distinct  advantages  have  been  recognized: 
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1.  Ability  to  State  Asynchronuous  Timing 
Asynchronuous  timing  in  a   system  is   the  most  common 

timing  method  in  any  computer  system,  be  it  the  reaction  on 
the  completion  of  some  task  or  dealing  with  an  external 
interrupt.  The  examples  presented  during  this  work  show  very 
clearly  that  every  event  displays  asynchronuous  timing  since 
it  reacts  on  certain  holding  conditions  whenever  they  might 
be  true.  By  stating  events  and  their  connected  places  we  can 
describe  the  asynchronuous  timing  easily. 

2.  Ability  to  Show  Dataflow  in  a  System 

The  combined  consideration  of  timing  and  dataflow  in 
a  system  has  been  accomplished  by  changing  the  original  token 
meaning  of  Petri  Nets  into  a  data  carrying  message.  This 
enables  the  methodology  to  exhibit  currently  available  data 
at  any  stage  of  the  process. 

3.  Ability  to  Model  Concurrency 

The  inherent  ability  of  Petri  Nets  to  model 
concurrency  by  activating  several  places  as  the  result  of  a 
transition  is  available  in  this  work  and  provides  a  useful 
construct. 

4.  Ability  to  Model  Mutual  Exclusion 

As  it  was  shown  in  different  examples  it  was  possible 
to  model  mutual  exclusion  simply  by  incorporating  a  structure 
of  control  places  into  nets  which  allow  only  one  access  to 
the  nets  or  to  of  parts  of  the  nets  at  a  time. 
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B.  DISADVANTAGES 

The  disadvantages  of  this  methodology  can  be  based  on  the 
properties  of  Petri  Nets  and  the  intended  accuracy  of  the 
speci  f  i cat ions. 

1 .  Compl ex  i  ty 

The  given  examples,  though  very  simple  and  small  in 
their  nature,  exhibit  a  large  complexity  in  stating  the 
specification.  This  complexity  is  largely  due  to  the  details 
involved  in  the  timing  of  systems  and  also  to  the  attempt  to 
handle  data  in  the  timing.  The  syntax  presented  is  only  one 
way  of  representing  formal  timing  specification  and  it  is 
very  tedious  for  the  user  to  deal  with  it,  therefore  a  future 
implementation  should  provide  an  user  interface  which  is  easy 
to  interact  with,  preferably  in  a  graphical  environment. 

2.  Difficulty  to  Model  Decisions 

Petri  Nets  by  their  nature  are  non-deterministic  and 
so  the  specification  methodology  presented  suffers  from  this 
disadvantage  when  we  are  forced  to  model  decisions.  The  idea 
introduced  of  "external  agents'*  helps  to  deal  with  this 
probl em. 

C.  FURTHER  RESEARCH  TOPICS 

This  work  has  been  a  basic  step  in  showing  the 
possibility  of  specifying  the  time  behavior  of  a  computer 
jsystem.  As  further  research  topics  we  suggest  the  following 
areas : 
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Automation  of  this  methodology  to  hide  the  complexity  of 
the  specification  from  the  user  by  providing  a  graphical 
interface 

Provision  of  automated  features  which  allow  the  user  to 
make  inquiries  about  the  specified  system,  e.g.  existence 
of  deadlocks,  history  of  invocations  of  certain  subnets, 
trace  of  certain  messages,  etc. 

Development  of  tools  which  are  able  to  analyze  and 
compare  the  performances  of  different  specifications 

Research  in  the  area  of  timed  Petri  Nets  where  actions 
can  be  specified  to  be  performed  within  a  specified  time 

Application  of  this  methodology  in  the  area  of  the  newly 
developed  computer  systems  using  transputers  and  their 
programming  language  OCCAM 
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APPENDIX  A;  EDITED  STATIC  SPECIFICATION  OF 
THE  ABSTRACT  PROCESSOR 

This  edited  specification  of  an  Abstract  Processor  is 
based  on  the  work  of  Yurchak  (1984).  It  uses  an  improved 
syntax  of  Davis  and  Yurchak  (1985)  which  is  considered  more 
meaningful.  Also,  some  minor  changes  to  correct  errors  have 
been  made.  The  specification  consists  of  two  parts:  the 
replacement  statement  which  provide  a  shortcut  for  stating 
frequently  used  properties,  and  the  specification  of  the 
various  resources. 


repl ace (X, S ) 

nequivrel (X, S ) ; " 
with 

wX(i, i)  =  true( ) ; 

X(i,  j)  =  X( j,  i ) ; 

impl  ies(and(X(  i  ,  j)  ,X(  j,  k)  )  ,X(  i,  k)  )  =  trueOj" 

rep  1  ace ( X,  S) 

"ref lexive(x,S)  ;w 
wi  th 

"X(i, i)  =  true( ) ;" 

rep  1  ace (X, S) 

"comrautati ve ( X, S ) ; " 
with 

"X(i, j)  =  X( j, i) ;" 

replace(X, S) 

"transi tive(X, S )  ;  " 
wi  th 

"impl  ies(and(X(i,  j)  ,X(  j,  k)  )  ,X(i,k)  )  =  trueO;" 

replace(X, S) 

Massociative(X,S) ;w 
wi  th 

"X(i,X( j,k) )  =  X(X(i,j),k);M 

replace(X, S) 

"irref 1  ex i ve ( X, S ) ; " 
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wi  th 


"X(i,  i)    =    falseO  ; 


replace(X, S) 

"symmetrictX, S) ; " 
with 

nimpl ies(X(i, j) ,X( j, i) )  =  true();n 

rep  1  ace ( X, S) 

nantisymmetric(X,S) ;  " 
wi  th 

"impl ies(and(X< i,j),X(j,i)),(i==j)) 

replace(S.T) 

"idopers (S, T) ; M 
with 

"startT:  ->  S 

nextT:  S  ->  S 

prevT:  S  ->  S 

eqT:  S, S  ->  bool ; " 

replace(S,T) 

"idaxiomsCS, T) ; M 
wi  th 

MprevS( startT( ) )  is  undefined; 
prevS(nextS ( i  )  )  =  i; 
if  i  !=  startT() 
then 

nex tS (prevS ( i )  )  =  i; 
endi  f ; 
equivrel ( eqS, S ) ;  w 

replace ( S ) 

"typingopers ( S  )  ;  M 
wi  th 

"typeS:  ->  type; 

atomofS:  va 1  ->  S; 

valof S:  S  ->  val ; n 

rep  lace ( S) 

Mtypingaxioms(S) ;M 
wi  th 

Mwhattype(valofS(t) )  =  typeS(); 

atomofS( valof S( t) )  =  t; 

if  whattype(v)  =  typeS() 

then 

valof S(atomof S( v) )  =  v; 

e  1  se 

atomofS(v)  is  undefined; 

endi  f  ;  M 

replace(S,T) 


=  true( ) ; " 
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with 


relop(S,T) ; n 

Happlyrop(ST( ) , vl, v2)  = 

valof bool (TS(atomof S(vl ) , atomof S( v2) )  )  ;  w 


replace (S) 

nisops (S) ; " 
with 

nif  whattype(v)  =  typeSC) 
then 

app 1 ybop ( i sS (),  v )  =  va I  of boo  1  ( true ( ) ) ; 
e  1  se 

app 1 ybop ( i sS (), v )  =  va 1  of boo  1 ( f a  1 se ( ) ) ; 
endi  f ; n 

replaceCS, T) 

nstateaxioms(S,T) ;  M 
wi  th 

wf etchS (a, ini tam ( ) )  is  undefined; 

storeS(fetchS(a,q)fa,q)  =  q ;" 

impl ies ( eqT(al , a2) , fetchS (al , storeS ( v, a2, q ) )  =  v) 

=  true ( )  ; 
implies(not(eqT(al,a2),fetchS(al,storeS(v,a2,q)) 
f  etchS(al,  q)  )  =  trueOj" 


Resource  boolean  is 

Extension  of 

Operand  Types 
boo  1  ; 

Operators 

true :  ->  boo  1  ; 

false:  ->  boo  1  ; 

not:  bool  ->  bool; 

and:  bool, bool  ->  bool; 

Derived  Operators 

or:  bool, bool  ->  bool; 
implies:  bool, bool  ->  bool; 

Derived  Definition 

or(bl,b2)  =  not(and(not(bl) ,not(b2) ) ) ; 
impl ies(bl,b2)  =  not (and ( bl , not ( b2) ) ) ; 

Properties 

false  =  not(trueO); 

not (not (b ) )  =  b ; 

and ( true ( ) , b )  =  b ; 

and  (  f  a  1  se  (  )  ,  b  )  =  falseO; 
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commutative (and, boo  1 ) ; 
end  boolean; 


Resource  natural  is 

Extension  of 
boo  1 ean 

Operand  Types 
nat ; 

Operators 

zeronat:  ->  nat; 
prednat:  nat  ->  nat; 
succnat:  nat  ->  nat; 
sumnat:  nat, nat  ->  nat; 
mltnat:  nat, nat  ->  nat; 
divnat:  nat, nat  ->  nat; 
eqnat :  nat, nat  ->  bool; 
gtnat:  nat, nat  ->  bool; 

Derived  Operators 

ltnat:  nat, nat  ->  bool 
genat:  nat, nat  ->  bool 
lenat:  nat, nat  ->  bool 
nenat:  nat, nat  ->  bool 


Derived  Definition 


1 tnat (n, m ) 
genat (n, m) 
1  enat (n, m) 
nenat (n, m) 


not (or ( gtnat (n, m) , eqnat (n, m) ) ) ; 
not ( 1 tnat (n, m) ; 
not ( gtnat ( n, m) ; 
not ( eqnat (n, m) ; 


Properties 

prednat ( zeronat () )  is 
prednat (succnat (n) )  = 
succnat ( prednat (n) )  = 
sumnat (n, zeronat () )  = 


undef  ined ; 

n; 

n; 

n; 

sumnat (n, succnat ( m) )  =  succnat ( sumnat (n, m) ) ; 
subnat (n, zeronat () )  =  n; 
if  gtnat(n,m)  =  trueO 
then 

subnat (n, succnat (m) ) 
e  1  se 

subnat (n, succnat(m) ) 
end  i  f ; 

ml  tnat  (  x  ,  zeronat  ()  )  =  zeronatO  ; 
m  1  tnat ( x , succnat ( zeronat ()) )  =  x; 
mltnat(x,y)  =  sumnat ( x , m 1 tnat ( x , prednat (y ))) ; 
if  eqnat  (  y,  zeronat  ()  )  =  trueO 


=  prednat ( subnat (n, m )) ; 
is  undefined; 
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then 

divnat(x,y)  is  undefined; 
else  if  ltnat(x,y)  =  trueO 
then 

divnat(x,y)  =  zeronat; 
e  1  se 

divnat(x,y)  =  sumnat ( succnat ( zeronat ()  , 
divnat(subnat(x,y) ,y) ) ; 
end  i  f ; 
endi  f ; 

eqnat(n,m)  =  eqnat ( succnat (n) , succnat (m) ) ; 
gtnat ( succnat (n) , n)  =  trueO; 
equivrel (eqnat, nat) ; 
irreflexive(gtnat,nat) ; 
irref lexive( 1 tnat, nat ) ; 
transitive(gtnat,nat) ; 
transitiveCl tnat, nat) ; 
transitive(genat,nat) ; 
transitive( lenat,nat) ; 
antisymmetric(genat,nat) ; 
ant i  symmetr  ic ( 1 enat , nat )  ; 
symmetr ic (nenat , nat ) ; 
commutat  i ve ( sum nat , nat ) 
commutative (ml tnat, nat) 
associative (sumnat, nat ) 
associative(ml tnat, nat) 


end  natura 1 ; 


Resource  integer  is 

Extension  of 
boo  1 ean, 
natura 1 

Operand  Types 
int ; 


Operators 

zeroint :  ->  int ; 
ntoi :  nat  ->  int ; 
i  ton :  int  ->  nat ; 
predint:  int  ->  int; 
succint:  int  ->  int; 
sumint:  int, int  ->  int 
mltint:  int, int  ->  int 
divint:  int, int  ->  int 
modint:  int, int  ->  int 
eqint:  int, int  ->  bool 
gtint:  int, int  ->  bool 
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Derived  Operators 

ltint:  int, int  ->  bool; 
geint:  int, int  ->  bool; 
leint:  int, int  ->  bool; 
neint:  int, int  ->  bool; 


Derived  Definition 


1 t int (n, m)  = 

geint (n, m)  = 

1 eint (n, m)  = 

neint (n, m)  = 

Properties 

predint(succint( 
succint(predint( 
ntoi (zeronat( ) ) 
ntoi (succnat(n) ) 

sumint ( succi 
i  ton( zeroint ( ) ) 
if  1  tint  <  x , zeroi 
then 

i  ton ( x )  is  u 
e  1  se 

i ton( succint 
succnat ( 
endi  f  ; 

if  1  tint ( x , zeroi 
then 

abs  int ( x )  = 
e  1  se 

abs  int ( x )  = 
endi  f ; 

sumint (n, zeroint 
sumint (n, succint 
sub int (n, zeroint 
subint(n, succint 

subint (n, sue 
ml  tint (x, zeroint 
ml tint(x, succint 
m 1 t int ( x , y )  =  su 
if  eqint (y , zero  i 
then 

di  v  int ( x , y ) 
else  if  1 t  int (ab 
then 

di  v  int ( x , y ) 
else  if  or ( 

and ( gt in 

gtin 

and ( 1  tin 

1  tin 

)  =  true 


not(or(gtint(n,m) ,eqint(n,m) ) ) ; 
not ( 1 t int (n, m) ; 
not ( gtint (n, m) ; 
not (eqint (n, m) ; 


n) )  =  n; 
n) )  =  n; 
=  zeroint ( ) ; 

nt(zeroint( ) ) ,ntoi (n) ) ; 
=  zeronat ( ) ; 
ntO)  =  trueO 

ndef  ined ; 

( x ) )  =  sumnat ( 
zeronat ( ) , iton(x) )  )  ; 

ntO)  =  trueO 

subint(zeroint( )  ,  x) ; 

x; 

( ) )  =  n; 

(m))  =  succint ( sumint (n, m) ) ; 

( ) )  =  n; 

(m))  =  pred int ( subint (n, m) ) ; 

cint(m) )  is  undefined; 

( ) )  =  zeroint ( ) ; 

( zero  int ( ) ) )  =  x ; 

mint(x, ml tint(x, predint(y) ) ) ; 

ntO)  =  trueO 


is  undefined; 
sint(x),absint(y) ) 

=  zeroint ; 

t ( x , zeroint ( ) ) , 
t (y , zero  int ( ) ) ) , 
t ( x , zeroint ( ) ) , 
t (y, zeroint ()) ) 
(  ) 


=  true ( ) 
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then 

divint(x,y)  =  sumint < succint ( zeroint ( ) , 
divint ( subint ( x, y) ,y) ) ; 
else 

divint(xfy)  =  sumint (predint ( zeroint () , 
divint(sumint(x,y),y) ) ; 
end  i  f ; 
end  i  f  ; 
end  if  ; 

if  gt  int  (m,  zeroint  ()  )  =  trueO 
then 

if  1  tint (n, zeroint () )  =  trueO 

then 

modint (n, m)  =  modint ( sumint (n, m) , m) ; 

e  1  se 

modint(n,m)  =  subnat(n, 

m 1 tnat (m,divint(n,m) ) ) ; 

end  i  f ; 
e  1  se 

modint(n,m)  is  undefined; 
endi  f ; 

eqint(n,m)  =  eqint ( succint (n ), succint (m) ) ; 
gt  int  (  succint  (n  ),  n)  =  trueO  ; 
equivrel (eqint, int) ; 
irreflexive(gtint, int) ; 
irref lexive( 1  tint, int) ; 
trans  itive(gtint, int) 
transitiveC 1  tint, int) 
transitive(geint, int) 
transitiveC leint, int) 
antisymmetric(geint, int) ; 
ant  i  symmetr  ic( leint, int) ; 
symmetric(neint, int) ; 
commutat i ve ( sumint , int) 
commutat i  ve(mltint,  int) 
associative( sumint , int ) 
associativednl  tint,  int) 


end  i  nteger ; 


Resource  character  is 

Extension  of 
boo  1 ean 

Operands 
char  ; 


Operators 

' A' ,'B' 


»  r » 
>  w  , 


'a' , 'b' , 'c' , 


'Z' 
'z' 


->  char ; 
->  char ; 
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I  »  » 

» 

_  *  » 

»  »  » 

> 

I  »  » 


NUL 

SOH 

STX 

EXT 

EOT 

ENQ 

ACK 

BEL 

BS: 

HT: 

LF: 

VT: 

FF: 

CR: 

SO: 

SI  : 

DLE 

DC1 

DC2 

DC3 

DC4 

NAK 

SYN 

ETB 

CAN 

EM: 

SUB 

ESC 

FS 

GS 

RS 

US 

SP 

DEL: 

eqcha 

gtcha 


i 

w » 

» 

2' 

-> 

-> 

-> 

-> 

-> 

-> 

-> 

-> 

> 

> 

> 

> 

> 

> 

> 

> 

-> 

-> 

-> 

-> 

-> 

-> 

-> 

-> 

-> 

> 

-> 

-> 

> 

> 

> 

> 

> 

-> 

r  : 

r  : 


»  + »  »  —  »  t  —  i 


i  ^ » 


&', '*' , » (' 


»  » 


»*?  »/»  »%»  »  r  * 
.»  »  »  »»   »^»  » s  >  »•?»  »/ 


»  •  > 

->  char; 
, '3» , '4' , '5' , '6' 


-> 
-> 
-> 


char ; 
char  ; 
char ; 


»7», '8' , »9' , »0' 


->  char; 


char 

char 

char 

char 

char 

char 

char 

char 
char ; 
char ; 
char ; 
char ; 
char  ; 
char ; 
char  ; 
char  ; 

char 

char 

char 

char 

char 

char 

char 

char 

char 
char  ; 

char 

char 
char  ; 
char  ; 
char  ; 
char  ; 
char  ; 

char ; 

char, char  ->  bool; 

char, char  ->  bool; 


Derived  Operators 

1 tchar :  char, char  ->  bool; 
gechar :  char, char  ->  bool; 
lechar:  char, char  ->  bool; 
nechar:  char, char  ->  bool; 


Derived  Definition 
1 tchar ( n, m) 
gechar (n, m ) 
1 echar ( n, m ) 


not(or(gtchar(n,m),eqchar(n,m) ) ) ; 
not( ltchar(n,m) ) ; 
not(gtchar(n,m) ) ; 
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nechar(n,m)    =    not ( eqchar (n, m) ) ; 


p 

roper  ties 

gtchar 

CDLE 

»  ~  »  > 

=  true 

gtchar 

■ »  ~  t 

,  '  }'  ) 

=  true 

gtchar 

CM' 

9    t    1    \ 

9          '    ' 

=  true 

gtchar 

■  ?  i  f 

,  '  {'  ) 

=  true 

gtchar 

('{' 

,  'z'  ) 

=  true 

gtchar 

(  '  Z* 

■   9       •   • 

a'  )  =  t 

gtchar 

C '  a* 

'   '   '   ) 

=  true 

gtchar 

■    f     i    l 

t                »   ) 

=  true 

gtchar 

»■«■»> 

=  true 

gtchar 

■       f        A   » 

,   '   ]'   ) 

=  true 

gtchar 

[']» 

,   '   "   ) 

=  true( 

gtchar 

'  »  » 

'CM 

=  true( 

gtchar 

['[' 

,  'Z'  ) 

=  true 

gtchar 

:'Z' 

f  •  •  • 

A'  )  =  t 

gtchar 

;  'A' 

,  '  @'  ) 

=  true 

gtchar 

:»©» 

'  ? '  ) 

=  true 

gtchar 

!  *  ?' 

,  '  >'  ) 

=  true 

gtchar  < 

:*  >' 

*  =  *  ) 

=  true 

gtchar 

; » s» 

,  •<•  ) 

=  true 

gtchar i 

: '  <' 

»  »  » 

=  true 

gtchar 

f  *  • ' 

>  » 

»  .  »  ^ 

=  true 

gtchar  < 

'  *  * 

,  '9'  ) 

=  true 

gtchar 

['9' 

f  •  •  * 

0'  )  =  t 

gtchar  < 

'0' 

,  '/'  ) 

=  true 

gtchar 

: '  /' 

'  '  ) 

=  true 

gtchar 1 

' . 

'  —  *  i 

=  true 

gtchar l 

:  *  -' 

»  >  * 

=  true 

gtchar  < 

» 

,  '  +'  ) 

=  true 

gtchar 1 

; *  + ' 

,  '  *  '  ) 

=  true 

gtchar  < 

' * » 

,  '  )  »  ) 

=  true 

gtchar 1 

: ' ) ' 

,  '  ('  ) 

=  true 

gtchar  < 

'  ( ' 

'  '  '  ) 

=  true 

gtchar  < 

■ » » » 

,  '&'  ) 

=  true 

gtchar  < 

'&' 

,  '%'  ) 

=  true 

gtchar  < 

:'*' 

,  '  $'  ) 

=  true 

gtchar ( 

p  $» 

,  '  #'  ) 

=  true 

gtchar 1 

: » #' 

»  n »  ) 

=  true 

gtchar ( 

»  m  » 

»  »  »  ) 

=  true 

gtchar  < 

'  !  ' 

,SP) 

=  true( 

gtchar  < 

SP, 

US)  = 

true ( ) 

gtchar  < 

US, 

RS)  = 

true ( ) 

gtchar  < 

RS, 

GS)  = 

true ( ) 

gtchar  < 

GS, 

FS)  = 

true ( ) 

gtchar ( 

FS, 

ESC) 

=  true ( 

gtchar  < 

ESC 

,SUB) 

=  true 

gtchar ( 

SUB 

,EM) 

=  true( 

gtchar  < 

EM, 

CAN) 

=  true( 

gtchar ( 

CAN 

,ETB) 

=  true 

( ) 
( ) 
( ) 
() 
() 

rue ( ) ; 
(  ) 
() 
(  ) 
(  ) 

); 
); 
(); 

rue ( ) ; 
(  ) 
(  ) 
(  ) 
(  ) 
(  ) 
() 
(  ) 
(  ) 

rue ( ) ; 
(  ) 
(  ) 
(  ) 
(  ) 
(  ) 
(  ) 
(  ) 
(  ) 
(  ) 
(  ) 
(  ) 
(  ) 
(  ) 
(  ) 
(  ) 
)  ; 


)  ; 
(  ) 

)J 

>; 

( ) 
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gtchar(ETB,SYN)  =  trueO 
gtchar(SYN,NAK)  =  trueO 
gtchar (NAK,DC4)  =  trueO 
gtchar(DC4,DC3)  =  trueO 
gtchar(DC3,DC2)  =  trueO 
gtchar(DC2,DCl)  =  trueO 
gtchar (DC 1, DLE)  =  trueO 
gtchar (DLE, SI )  =  trueO; 
gtchar (SI , SO)  =  trueO; 
gtchar (SO, CR)  =  trueO; 
gtchar (CR, FF)  =  trueO; 
gtchar(FF,  VT)  =  trueO; 
gtchar(VT,LF)  =  trueO; 
gtchar(LF,HT)  =  trueO; 
gtchar(HT, BS)  =  trueO; 
gtchar (BS, BEL)  =  trueO; 
gtchar(BEL, ACK)  =  trueO 
gtchar (ACK, ENQ)  =  trueO 
gtchar(ENQ,EOT)  =  trueO 
gtchar(EOT,ETX)  =  trueO 
gtchar  (ETX,  STX)  =  trueO 
gtchar(STX,SOH)  =  trueO 
gtchar(SOH,NUL)  =  trueO 
equivrel (eqchar,char) ; 
irref lexive(gtchar, char) ; 
transitive(gtchar,char) ; 
irref lexive( ltchar,char) ; 
transitiveC 1 tchar, char) ; 
transitive(gechar, char) ; 
transitive( lechar)char) ; 
ant i  symmetr  ic ( gechar , char ) ; 
anti  symmetr  ic( lechar, char) ; 
symmetr ic ( nechar ) ; 


end  ; 

Resource  string ( e 1 e lment)  is 
Parameter  element  is 

Extension  of 

boo  1 ean 

Operands 
I  m ; 

Operators 

eqlm:  lm,lm  ->  bool; 
gtlm:  lm,lm  ->  boo  1 ; 

Derived  Operators 
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ltlm:  1  rn,  1  m  ->  boo  1  ; 
gelm:  lm,lm  ->  bool; 
lelm:  lm,  1 m  ->  boo  1 ; 
nelm:  lm,lm  ->  bool; 
Derived  Definition 

ltlm(n,m)  =  not (or ( gt 1 m(n, m) , eql m(n, m) ) ) ; 

gelm(n,m)  =  not ( 1 t lm(n, m) ) ; 

lelm(n,m)  =  not ( gt 1 m (n, ra) ) ; 

nelm(n,m)  =  not (eq 1 m (n, m) ) ; 

Properties 

equivre 1 ( eq 1 m, 1  m) ; 
irreflexive(gtlm, lm); 
transitive(gtlm, lm) ; 
irreflexive(ltlm, lm); 
transitive( ltlm, lm) ; 
transitive(gelm, lm); 
trans  itive( lelm) lm) ; 
ant isymmetr  ic(ge 1 m,  lm) ; 
antisymmetric( lelm, lm) ; 
symmetr  ic(nelm) ; 

Extension  of 
natura 1 ; 
boo  1 ean ; 

Operands 

str . 1 m ; 


Operators 

nu 1 1 s tr .  1  m 
makestr . 1 m 
1 enstr . 1 m : 
heads tr .  1  m 
tai 1 str .  1  m 
cats tr. 1 m : 


->  s tr . 1 m ; 
1 m  ->  str . 1 m ; 
str . 1 m  ->  nat ; 
str . 1 m  ->  1 m ; 
str . 1 m  ->  str . 1 m ; 
s tr . 1 m, s tr . 1 m  ->  str. 
eqstr.lm:  s tr . 1 m, s tr . 1 m  ->  bool; 
gtstr.lm:  s tr . 1 m, s tr . 1 m  ->  bool; 


1  m ; 


Derived  Operators 

ltstr.lm:  str . 1 m, str . 1 m  ->  bool; 

gestr.lm:  s tr . 1 m, s tr. 1 m  ->  bool; 

lestr.lm:  str . 1 m, str . 1 m  ->  bool; 

nestr.lm:  s t r . 1 m, s tr . 1 m  ->  bool; 
Derived  Definition 

1 ts tr . 1 m (n, m)  = 

not(or(gtstr. lm(n,m),eqstr. lm(n,m))); 

ges tr . 1 m (n, m )  =  not ( 1 tstr . 1 m (n, m) ) 

1 es tr . 1 m (n, m )  =  not ( gtstr . 1 m (n, m ) ) 

nestr . 1 m (n, m)  =  not ( eqs t r . 1 m (n, m ) ) 


Properties 
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lenstr.  lmCnul  1  str.  lm( ) )  =  zeronatO; 

lenstr. lmdnakestr. lm( 1 ) )  =  succnat (zeronat ( ) ) ; 

1 enstr. ImCcatstr. 1 mC si , s2) )  = 

sumnat (1  en str.  lm(sl),  1  en str.  Im(s2)); 
heads tr . 1 mdnakestr . 1 m ( 1 ) )  =  1; 
tai 1 str . 1 m (makestr . 1 m ( 1 ) )  =  nul lstr. lm() ; 
heads tr.  1 m C cats tr .  1 m Cmakestr .  1 m C 1 ), s  )  )  =  1; 
tai 1 str. ImCcatstr. lmdnakestr . 1 m < 1 ) , s) )  =  s; 
headstr. 1 m(nul 1 str. lm( ) )  is  undefined; 
tai 1 str .  lm(nul 1 str .  1 m ( ) )  =  nu 1  1 str .  1  m(  )  ; 
catstr. 1 m C catstr . 1 m C si , s2) , s3)  = 

catstr. lm(sl, catstr. Im(s2,s3)); 
catstr. 1 m(nu 1 1 str. lm( ), s)  =  catstr. lm( 

s, nu 1 1 str . 1 m ( ) )  =  s ; 
implies(eqlm(ll, 1 2) , eqstr . lm( makestr. lmC 1 1 ) , 

makestr  .  1  m  (  1  2)  )  )  =  trueO  ; 
impliesCgtlmCll, 1 2) , gts tr . lmdnakestr. 1  m  C  1  1  )  , 

makestr  .  1  m  (  1  2)  )  )  =  trueO  ; 
gtnat(  lenstr.  lmdnakestr.  lm(  1  )  , 

1  enstr  .  1  m  (nu  1  1  str  .  1  m  (  )  )  =  trueO  ; 
implies(gtnat(lenstr. lm(sl), lenstr. Im(s2)), 

gtstr  .  1  m  (  si ,  s2)  =  trueO  ; 
if  1  ens  tr  .  1  m  (  si )  !=  zeronatO 
then 

gtnat(lenstr. ImCcatstr. Im(sl,s2), 

1  enstr  .  1  m  (  s2)  =  trueO  ; 
e  1  se 

eqnat ( 1  ens tr .  ImCcatstr.  lmCsl,s2), 

lenstr . 1 mC s2)  =  trueC); 
endi  f  ; 

equivrel Ceqstr. lm, str. lm) ; 
irreflexiveCgtstr. lm,str. lm); 
transitiveCgtstr. 1 m, str . lm) ; 
irreflexiveC ltstr. lm,str. lm) ; 
transitiveCltstr. lm,str. lm); 
transitiveCgestr. lm, str. lm) ; 
transitiveC lestr. 1 m) str . lm) ; 
ant isymmetr  icCgestr.  lm,str.  lm) ; 
anti  symmetric  C lestr.  lm, str.  lm); 
symmetr  icCnestr.  lm, str.  lm); 


end  str ing Ce 1 ement ) ; 


Resource  str ing C character )  is 


where 

lm 


=  char ; 


nullstr.char  =  nullstr.lm; 
makestr. char  =  makestr. lm; 
len.char  =  lenstr. lm; 
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head. char  =  headstr.lm; 
tail. char  =  tailstr.lm; 
cat. char  =  catstr.lm; 
eq.char  =  eqstr.lm; 

gtstr . 1  m; 

1 tstr . 1 m ; 

gestr . 1 m ; 

lestr. 1  m ; 


gt. char 
1 t . char 
ge. char 
1 e. char 
ne. char 


=  nes tr. 1 m; 


end  str ing ( character ) ; 


Resource  identifiers  is 

Extension  of 

boo  1 ean 


Operands 

memid 
reg  id 
stk  id 
fid; 


Operators 

idopers  (memid  ,  mernsem  )  ; 
idopers(redid, regseg) ; 
idopers(stkid, stkseg) ; 
idopers(fid. fseg) ; 

Properties 

idaxiom(memid,memseg) ; 
idaxiom(regid, regseg) ; 
idaxiom(stkid, stkseg) ; 
idaxiom(fid, fseg) ; 


end 


Resource  memaddress  is 

Extension  of 

i  dent i  f  iers , 
boo  1 ean 

Operands 

memaddr ; 

Operators 

startmemaddr :  memid  ->  memaddr; 
nex tmemaddr :  memaddr  ->  memaddr; 
prevmemaddr:  memaddr  ->  memaddr; 
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getmemid:  memaddr  ->  memid; 
offset:  int, memaddr  ->  memaddr; 
eqmemaddr:  memaddr , memaddr  ->  bool; 


Properties 

prevmeraad 
prevmemad 
nextmemad 
offset ( su 
if  offset 
then 

of  f  se 
e  1  se 

of  f  se 
endi  f ; 
eqmemid ( i 

true  ( 
eqmemaddr 

eqmem 
eqmemaddr 
eqmemaddr 

eqmem 
of  f set ( ze 
eqi vre 1 <  e 

end  memaddress  ; 


dr ( s tar tmemaddr ( i ) )  is  undefined; 

dr (nex tmemaddr (m) )  =  m; 

dr ( prevmemaddr (m) )  =  m; 

ccint(n),m)  =  nex tmemaddr ( of f set (n, m) ) ; 

(n,m)  =  startmemaddr ( ) 

t (predint (n) , m)  is  undefined; 

t ( predint (n) , m)  =  prevmemaddr ( of f set (n, m) ) ; 

, getmemid (offset(n,startmemaddr(i))))  = 

); 

(startmemaddr(il),startmemaddr(i2))  = 

ldCil, i2) ; 

(  star  tmemaddr  (  i  ),  nex  tmemaddr  (a  )  )  =  falseO; 

(nex tmemaddr (al )  , nex tmemaddr (a2) )  = 

addr (al , a2) ; 

roint ( ) , m)  =  m; 

qmemaddr , memaddr ) ; 


Resource  regaddress  is 

Extension  of 

ident i  f  iers, 
boo  1 ean 

Operands 

regaddr  ; 

Operators 

star tregaddr :  regid  ->  regaddr; 
nextregaddr:  regaddr  ->  regaddr; 
prevregaddr:  regaddr  ->  regaddr; 
getregid:  regaddr  ->  regid; 
eqregaddr:  regaddr , regaddr  ->  bool; 

Properties 

prevregaddr ( startregaddr ( i ) )  is  undefined; 
prevregaddr ( nex tregaddr (m) )  =  m; 
nextregaddr ( prevregaddr (m) )  =  m; 

eqregaddr(startregaddr(il),startregaddr(i2))  = 

eqregid ( II, 12) j 
eqregaddr ( startregaddr ( i ), nex tregaddr (a ) )  =  falseO ; 
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eqregaddr(nextregaddr(al) ,nextregaddr(a2) ) 
eqregaddr(al,a2) ; 

eqivrel (eqregaddr, regaddr) ; 

end  regaddress; 

Resource  stkaddress  is 

Extension  of 

ident i  f  iers , 
boo  1 ean 

Operands 

stkaddr ; 

Operators 

getstkid:  stkaddr  ->  stkid; 
eqstkaddr:  stkaddr , atkaddr  ->  bool; 

Properties 

eqstkaddr (nextstkaddr(al) ,nextstkaddr(a2) ) 

eqstkaddr(al,a2) ; 
equivrel (eqstkaddr, stkaddr) ; 

end  stkaddress  ; 

Resource  files  is 

Extension  of 

ident  if iers, 
boo  1 ean 

Operands 
f  i  le; 

Operators 

getfile:  fid  ->  file; 
eqfile:  file, file  ->  bool; 


Properties 

eqf i le(getfile(il),getfile(i2)) 
equivrel (eqfi le, fi le) ; 

end  files; 

Resource  operatorc 1  asses  is 

Extension  of 


=  eqfile(il,i2); 
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Operands 
mop; 
dop; 
top; 
qop; 
sop; 
oop; 
rop; 
bop; 

Operators 

Properties 
end  operatorc 1  asses ; 
Resource  instruct iontype  is 

Extension  of 

Operands 

instr ; 

Operators 

Properties 
end  intruct iontype ; 
Resource  typing  is 

Extension  of 

boo  1 ean; 

natura 1 ; 

integer ; 

character ; 

str ing ( character ) ; 

ident i  f  ier s ; 

memaddress ; 

regaddress ; 

stkaddr ; 

files; 

operatorc lasses ; 

intruct iontype; 

Operands 
type; 
va  1  ; 

Operators 

typingopers(bool ) ; 
typingopers(nat) ; 
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typingopers I 

:int) ; 

typingopers 

[char ) ; 

typingopers ( 

! str . char ) ) ; 

typingopers 

[memid ) ; 

typingopers 1 

regid ) ; 

typingopers 

Istkid) ; 

typingopers  < 

!f id) ; 

typingopers 

[memaddr ) ; 

typingopers  < 

regaddr ) ; 

typingopers 

[ s tkaddr ) ; 

typingopers ( 

file); 

typingopers 

[mop) ; 

typingopers  < 

[dop) ; 

typingopers 

[top) ; 

typingopers  < 

qop)  ; 

typingopers 

[ sop) ; 

typingopers  < 

' oop) ; 

typingopers 

[ rop) ; 

typingopers  < 

bop)  ; 

typingopers 

[ i  ns tr  )  ; 

whattype:  va 1  ->  type; 
eqtype:  type, type  ->  bool; 


Properties 

typingax  iom 
typingax  iom 
typingax  i  om 
typingax  iom 
typingax  i  om 
typingax  iom 
typingax  iom 
typingax  iom 
typingax  iom 
typingax  iom 
typingax  iom 
typingax  i  om 
typingax  i  om 
typingax  i om 
typingax  iom 
typingax  iom 
typingax  i  om 
typingax  iom 
typingax  iom 
typingax  iom 
typingax  i  om 
typingax  i om 
equi  vrel  ( i  ns 

end  typing; 


boo  1  )  ; 
nat )  ; 
int )  ; 
char  )  ; 
str . char ) ; 
memid ) ; 
reg  id ) ; 
stkid)  ; 
fid)  ; 
memaddr ) ; 
regaddr ) ; 
stkaddr ) ; 
file); 
mop ) 
dop ) 
top) 
qop) 
sop ) 
oop) 
rop ) 
bop) 
ins tr  )  ; 
tr)  ; 
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Resource  operators  is 

Extension  of 

operatorc lasses, 
typing 

Operands 


Operators 

boo  1  not 
boo  1  and 
boo  1  or : 
natpred 
natsucc 
natsura : 
natsub : 
nateq : 
natgt : 
nat 1 t : 
intpred 
intsucc 
intabs : 
intntoi 
inti  ton 
intsum : 
intsub : 
intm 1 t : 
intdi  v : 
intmod : 
inteq : 
intgt : 
intl t: 
chareq : 
chargt : 
charmak 
charstr 
charhea 
chartai 
charcat 
str . cha 
str . cha 
i  sboo 1 : 
isnat : 
is  int : 
ischar : 
iss  tr .  c 
ismemid 
i  sregid 
isstk  id 
i  sf  id  : 
ismemad 
i  sregad 


:  ->  mop; 
:  ->  dop; 

->  dop; 
:  ->  mop; 
:  ->  mop; 

->  dop; 

->  dop; 
->  rop; 
->  rop; 
->  rop; 
:  ->  mop; 
:  ->  mop; 

->  mop; 
:  ->  mop; 
:  ->  mop; 

->  dop; 

->  dop; 

->  dop; 

->  dop; 

->  dop ; 
->  rop; 
->  rop; 
->  rop; 

->  rop ; 

->  rop; 
estr :  ->  mop ; 
1  en :  ->  mop; 
dstr :  ->  mop ; 
1  str :  ->  mop; 
s tr :  ->  dop ; 
req:  ->  rop; 
rgt :  ->  rop ; 

->  bop; 
->  bop; 
->  bop; 

->  bop; 
har :  ->  bop; 
->  bop; 
->  bop; 
->  bop ; 
->  bop ; 
dr :  ->  bop ; 
dr  :  ->  bop ; 
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isstkaddr:  ->  bop; 
isf  i 1 e :  ->  bop ; 
ismop:  ->  bopj 
isdop :  ->  bop ; 
istop:  ->  bop; 
isqop:  ->  bop; 
i  ssop :  ->  bop; 
isoop:  ->  bop; 
isrop:  ->  bop; 
isbop:  ->  bop; 
i  s  instr :  ->  bop ; 


app 
app 
app 
app 
app 
app 
app 
app 


Propert 
app 
app 

app 

app 

app 

app 

app 

app 

app 

app 

app 

app 

app 

app 

app 


ymop 
ydop 
ytop 
yqop 
ysop 
yoop 
yrop 
ybop 


es 

ymop  ( 
ydop( 
and  (a 
ydop( 
or  (at 
ymop  ( 
predn 
ymop( 
succn 
ydop( 
sumna 
ydop  ( 
subna 
ymop  ( 
pred  i 
ymop  ( 
succi 
ymop  ( 
abs  in 
ymop  ( 
ntoi  i 
ymop  ( 
i  toni 
ydop( 
sumin 
ydop  ( 
subin 
ydop  ( 
m  1  t  in 


mop, va 1  ->  va 1 ; 
dop, val , val  ->  va 1 ; 
top, va 1 , va 1 , va 1  ->  val; 
qop, va 1 , va 1 , va 1 , va 1  ->  val; 
sop, va 1 , va 1 , va 1 , va 1 , va 1  ->  val; 
oop, va 1 , va 1 , va 1 , va 1 , va 1 , va 1  -> 
rop, val, val  ->  val; 
bop, va 1  ->  val ; 


boo lnot ( 
boo  1  and ( 
tomof boo 
boo  1  or ( ) 
omof boo  1 
natpred ( 
at (atomo 
natsucc( 
at (atomo 
natsum ( ) 
t ( atomof 
natsub ( ) 
t ( atomof 
intpred ( 
nt (atomo 
intsucc ( 
nt ( atomo 
intabs ( ) 
t ( atomof 
intnto  i ( 
nt (atomo 
i  nt  i  ton ( 
nt (atomo 
i  ntsum ( ) 
t (atomof 
intsub ( ) 
t ( atomof 
intml t( ) 
t (atomof 


app 1 ydop ( intdi v ( )  ,  vl ,  v2)  =  valofint( 

di vint (atomof  int ( vl ) ,atomofint(v2) ) ; 
applydopC intmod ( )  ,  vl , v2)  =  valofint( 

mod int (atomof  int(vl) ,atomofint(v2) ) ; 
app 1 ymop ( charstr 1  en ( )  ,  v )  =  valofnat( 

lenstr. char(atomofstr. char(v) ) ) ; 
app 1 ymop ( charmakestr (), v )  =  va 1  of str . char ( 

makestr.char(atomofchar(v) ) ) ; 
app lymop(charheadstr ( ) , v )  =  valofchar( 

headstr.char(atomofstr.char(v) ) ) ; 
appl ymop (chartai 1 str (),  v )  =  va 1  of str . char ( 

tai lstr.char(atomofstr.char(v) ) ) ; 
app lydop(charcatstr ( ) , vl ,  v2)  =  va 1  of str . char ( 

catstr . char (atomofstr. char ( vl ) , 

atomof str. char ( v2) ) ) ; 


re  1  op 

[nat, eq ) ; 

re  1  op 

(nat, gt ) ; 

re  1  op ( 

[nat, It); 

re  1  op 

!  int , eq) ; 

re  1 opi 

:int,gt) ; 

re  1  op 

tint, It) ; 

re  1 op< 

! char , eq) ; 

re  1  op 

[ char ,  gt )  ; 

re  1 op< 

'str. char , eq) ; 

re  1  op 

[  str. char , gt ) ; 

i  sops ( 

boo  1 )  ; 

isops 

[nat ) ; 

i  sops  < 

int)  ; 

i  sops 

[char ) ; 

i  sops ( 

str . char ) ; 

isops 

[memi  d ) ; 

i  sops ( 

'  regid ) ; 

i  sops  < 

[stkid) ; 

i  sops  < 

fid)  ; 

isops  < 

[memaddr ) ; 

i  sops  ( 

regaddr ) ; 

isops  < 

!  s tkaddr ) ; 

i  sops  < 

file); 

i  sops i 

[mop) ; 

i  sops ( 

dop)  ; 

i  sops  < 

top)  ; 

i  s  o  p  s  < 

qop)  ; 

isops  < 

'  sop) ; 

i  sops  < 

oop)  ; 

i  sops  < 

[  rop) ; 

i  sops ( 

bop)  ; 

i  sops ( 

ins tr ) ; 

end  operators ; 
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Resource  intructions  is 


Extension  of 

natura 1 , 
integer , 
memaddress, 
regaddress , 
stkaddress , 
opera to re  1  asses, 
intructiontype, 
typing 

Operands 

Operators 

org :  ->  instr ; 
extern:  ->  instr; 
g 1 ob 1 :  ->  instr ; 
mbegin:  ->  instr; 
mend :  ->  instr ; 
offst:  int, regaddr  ->  inst 
link:  regaddr, nat  ->  instr 
unlink:  regaddr  ->  instr; 
monads:  mop, regaddr  ->  ins 
monad:  mop, regaddr , regaddr 
monadi:  mop, va 1 , regaddr  -> 
dyads:  dop, regaddr , regaddr 
dyadsi:  dop, va 1 , regaddr  -> 
dyad:  dop, regaddr , regaddr , 
dyadi:  dop, va 1 , regaddr , reg 
triads:  top, regaddr , regadd 
triadsi:  top, va 1 , regaddr, r 
triad:  top, regaddr , regaddr 
triadi:  top, va I , regaddr , re 
quads:  qop, regaddr , regaddr 
quad:  qop, regaddr , regaddr , 

regaddr , regaddr  ->  ins 
sexads:  sop, regaddr , regadd 

regaddr, regaddr, regadd 
sexad:  sop, regaddr , regaddr 

regaddr, regaddr, regadd 
octads:  oop, regaddr , regadd 

regaddr, regaddr, regadd 
octad:  oop, regaddr , regaddr 

regaddr, regaddr, regadd 
m  o  v  i _m :  val,memaddr  ->  ins 
movi_pcr:  val,int  ->  instr 
movi_r:  va 1 , regaddr  ->  ins 
movi_ri:  val, regaddr  ->  in 
movi_rid:  va 1 , regaddr , int 
movi_ridn:  va 1 , regaddr , nat 
mov_m_m:  memaddr , memaddr  - 


tr; 

->  instr ; 

instr ; 

->  instr ; 

instr ; 
regaddr  ->  instr; 
addr  ->  instr ; 
r, regaddr  ->  instr; 
egaddr  ->  instr; 
, regaddr , regaddr  ->  instr; 
gaddr , regaddr  ->  instr; 
, regaddr , regaddr  ->  instr; 
regaddr , 
tr; 

r , regaddr, 
r  ->  instr ; 
, regaddr, regaddr, 
r  ->  instr ; 
r, regaddr, regaddr, 
r, regaddr  ->  instr; 
, regaddr, regaddr, 
r , regaddr , regaddr  ->  instr; 
tr; 

tr; 

s tr  ; 

->  instr; 

, int  ->  instr ; 

>  instr ; 
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mov_m_r :  memaddr, regaddr  ->  instr; 
mov_m_ri:  memaddr , regaddr  ->  instr; 
mov_m_rid:  memaddr , regaddr , int  ->  instr; 
mov_m_ridn:  memaddr , regaddr , nat , int  ->  instr; 
mov_pcr_pcr:  int, int  ->  instr; 
mov_pcr_r :  int, regaddr  ->  instr; 
mov_pcr_ri:  int, regaddr  ->  instr; 
mov_pcr_rid:  int , regaddr , int  ->  instr; 
mov_pcr_r idn :  int , regaddr, nat , int  ->  instr; 
mov_r_m:  regaddr , memaddr  ->  instr; 
mov_r_pcr :  regaddr, int  ->  instr; 
mov_r_r:  regaddr , regaddr  ->  instr; 
mov_r_ri:  regaddr , regaddr  ->  instr; 
mov_r_rid:  regaddr , regaddr , int  ->  instr; 
mov_r_ridn:  regaddr , regaddr , nat , int  ->  instr; 
mov_ri_m:  regaddr , memaddr  ->  instr; 


mov  r 


mov_ri_r:  regaddr , regaddr  ->  instr; 


_pcr:  regaddr, int  ->  instr; 


_ri:  regaddr , regaddr  ->  instr; 
_rid:  regaddr, regaddr, int  ->  instr; 
_ridn:  regaddr , regaddr , nat , int  ->  instr; 


mov_r 

mov_r 

mov_r 

mov_rid_m:  regaddr , int , memaddr  ->  instr; 

mov_rid_pcr:  regaddr, int , int  ->  instr; 

mov_rid_r:  regaddr , int , regaddr  ->  instr; 

mov_rid_ri:  regaddr , int , regaddr  ->  instr; 

mov_rid_rid:  regaddr , int , regaddr , int  ->  instr; 

mov_r id_r idn :  regaddr , int, regaddr , nat , int  ->  instr; 

mov_r 

mov_r  i 

mov  r 


dn_m:  regaddr , nat , int , memaddr  ->  instr; 

dn_pcr :  regaddr , nat , int , int  ->  instr; 

dn_r :  regaddr , nat , int , regaddr  ->  instr; 
mov_ridn_ri:  regaddr , nat , int ,  regaddr  ->  instr; 
mov_r idn_r id :  regaddr , nat , int , regaddr , int  ->  instr; 
mov_r  idn_r  idn:  regaddr, nat, int, regaddr, nat, 

int  ->  instr ; 
push_i :  val,stkaddr  ->  instr; 
push_m:  memaddr , stkaddr  ->  instr; 
push_pcr:    int, stkaddr  ->  instr; 
push_r:  regaddr , stkaddr  ->  instr; 
push_ri:  regaddr , stkaddr  ->  instr; 
push_rid:  regaddr , int , stkaddr  ->  instr; 
push_ridn:  regaddr , nat , int , stkaddr  ->  instr; 
pop_x :  stkaddr  ->  instr; 
pop_m:  stkaddr , memaddr  ->  instr; 
pop_pcr :  stkaddr, int  ->  instr; 
pop_r:  stkaddr , regaddr  ->  instr; 
pop_ri:  stkaddr , regaddr  ->  instr; 
pop_rid:  stkaddr , regaddr , int  ->  instr; 
pop_ridn:  stkaddr , regaddr , nat ,  int  ->  instr; 
nop:  ->  instr; 
stop :  ->  instr ; 
jmp:  memaddr  ->  instr; 
jmp_i :  memaddr  ->  instr; 
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jmp_r:  regaddr  ->  instr; 

bra:  int  ->  instr; 

bra_r:  regaddr  ->  instr; 

if:  re  I  op, regaddr , regaddr , memaddr  ->  instr; 

ifi:  re  1  op, regaddr , va 1 , memaddr  ->  instr; 

ifte:  re  1  op, regaddr , regaddr , memaddr , memaddr  ->  instr; 

iftei:  re  1  op, regaddr , va 1 , memaddr , memaddr  ->  instr; 

if_pcr:  re  1  op, regaddr , regaddr , int  ->  instr; 

ifi_pcr:  re  1  op, regaddr , va I , int  ->  instr; 

ifte_pcr:  re  1  op, regaddr , regaddr , int , int  ->  instr; 

iftei_pcr:  re  1  op, regaddr , va 1 , int ,  int  ->  instr; 

test:  bop, regaddr , memaddr  ->  instr; 

testm:  bop, memaddr , memaddr  ->  instr; 

teste:  bop, regaddr , memaddr , memaddr  ->  instr; 

testme:  bop, memaddr , memaddr , memaddr  ->  instr; 

test_pcr:  bop, regaddr , int  ->  instr; 

testm_pcr:  bop, memaddr , int  ->  instr; 

teste_pcr:  bop, regaddr , int , int  ->  instr; 

testme_pcr:  bop, memaddr , int , int  ->  instr; 

jsr:  memaddr , stkaddr  ->  instr; 

jsr_i:  memaddr , stkaddr  ->  instr; 

jsr_r:  regaddr , stkaddr  ->  instr; 

bsr:  int, stkaddr  ->  instr; 

bsr-r:  regaddr , stkaddr  ->  instr; 

rts:  stkaddr  ->  instr; 

open:  stkaddr  ->  instr; 

close:  stkaddr  ->  instr; 

read:  stkaddr  ->  instr; 

write:  stkaddr  ->  instr; 


Properties 
end  intructions; 

Resource  amstate  is 

Extension  of 
boo  1 ean, 
natura 1 , 
integer , 
str(character) , 
memaddress , 
regaddress , 
f  i  1  es  , 

ident  i  f  ier s , 
typing 

Operands 

state ; 

Operators 
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me 
re 
va 
va 
-> 
s 


f etchm : 
f etchr : 
storem: 
storer : 
ini  tam : 
ini  ts tk 
topstk:  st 
pushstk:  v 
popstk:  st 
la  1 1 oc:  na 
1  free :  mem 
indir:  nat 
inf  i 1 e :  f  i 
outf  i 1 e :  v 
openf  ile: 
cl osef  ile: 
rmode:  -> 
wmode  :  -> 
rwmode : 
openerr : 
openok : 
valdata:  - 
chardata : 


maddr, state  ->  va 1 ; 
gaddr, state  ->  val; 
1 , memaddr, state  ->  state; 
1 , regaddr, state  ->  state; 

state ; 
tkaddr, state  ->  state; 
kaddr, state  ->  val 
a  1 , stkadd~ 


:kaddr, state  ->  val; 

'a  1 , stkaddr , state  ->  state; 

tkaddr , state  ->  state; 

it, state  -.  memid; 


t , state  - .  memid ; 
id, state  ->  state, 
'-addr  ->  memaddr; 
tate  -> 


mid, state  -?    state; 

t, memaddr  ->  memaddr; 

ile, state  ->  va 1 ; 

val , f i 1 e, state  ->  state; 

str. char, f i 1 e, int, int, state  ->  state; 
:  file, state  ->  state; 

int ; 

int : 

>  int : 
->  int ; 

>  int ; 
->  int ; 

->  int; 


active:  memid, state  ->  bool; 


Properties 

topstk 
popstk 
popstk 
s tatea 
statea 
topstk 
popstk 
act i  ve 
act i  ve 
act  ice 
act  i  ve 
act i  ve 
active 
active 
active 
act i  ve 
active 
act i  ve 
if  act 
then 

fe 
endi  f  ; 
if  act 
then 

st 


( s , ini tstk ( s ) )  is  undefined; 
( s , ini tstk ( s ) )  is  undefined; 
(s,  initamO)  is  undefined; 
x  iom( m, memaddr ) ; 
xiom(r, regaddr) ; 

s ( pushstk ( v, s , q) )  =  v; 

s ( pushstk (v , s , q) )  =  q; 

m,initam())  =  falseO  ; 

1  a  1  1  oc  (  n,  q)  q)  =  trueO  ; 

m,  1 f ree (m, q) )  =  false(); 

m, storer ( v , r , q ) )  =  active(m,q); 

m,  storem ( v , a, q) )  =  act i ve (m, q ) ; 

m, ini tstk ( s , q) )  =  active(m,q); 

m, pushstk ( v, s , q )  =  active(m,q); 

m, popstk ( s , q)  =  act i ve ( m, q ) ; 

m,  outf i 1 e ( v, f , q )  =  active(m,q); 

m, openf i 1 e < s , f , x , y, q )  =  active(m,q); 

m, c 1 osef i 1 e ( f , q )  =  active(m,q); 
i ve (m, q)  =  f a  1 se (  ) 

tchm ( of f set (n, m) , q)  is  undefined; 

i  ve (m, q )  =  f a  1 se ( )  ; 

orem ( v, of f set (n, m) , q)  is  undefined; 
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endi  f ; 

if  1 t int <n, ntoi (n2) )  =  trueO 

then 

offset(n,offset(nl,startmemaddr( 
lal loc(n2,q) ) ) )  = 
of  f set ( sum int (n, nl ) , 
startmemaddr( lal 1 oc(n2, q) ) ) ; 
e  1  se 

offset(n,offset(nl,startmemaddr( 
1  a  1 1 oc(n2, q) ) ) )  is  undefined; 
endi  f ; 

indi r (zeronat ( ) , m)  =  m ; 

if  whattype ( f etchm( indi r (n, m) , q)  =  typememaddr ( ) 
then 

indi r ( succnat (n)  ,  m )  = 

atomofmemaddr(fetchm(indir(n,m)  ,q) )  ; 
e  1  se 

i ndi r ( succnat (n) , m)  is  undefined; 
endi  f  ; 

openf i 1 e ( s, f , n, openf i 1 e ( s , f , m, x ,  q)  )  is  undefined; 
c 1 osef i 1 e ( f (openf i 1 e(s, f , n, x, q) )  =  q; 
inf i 1 e ( f , ini tarn () )  is  undefined; 
inf i 1 e ( f , c 1 ose ( f , q ) )  is  undefined; 

inf i 1 e ( f , openf i 1 e ( s , f , wmode (), x , q) )  is  undefined; 
outf i 1 e ( v, f , ini tarn () )  is  undefined; 
outf i 1 e ( v, f , c 1 ose ( f , q ) )  is  undefined; 

outf i 1 e ( v, f  ,  openf i 1 e ( s , f , rmode (),  x,  q ) )  is  undefined; 
outif le(v, f, openfi le(s, f, m, chardata( ) , q) ) 

i  s  undef  ined ; 


end  amstate; 


Resource  am  is 

Extension  of 

memaddress , 
intructiontype, 
typing, 
amstate 

Operands 

prog:  memaddr , state  ->  state; 

cond :  va 1 , memaddr , memaddr  -  memaddr; 
exq:  ins tr , memaddr , state  ->  state; 

Operators 

prog(m,q)  =  exq (atomof instr ( f etchm (m, q ) ) , m, q) ; 
cond ( va 1  of boo  1  ( true ( ) , ml , m2)  )  =  ml; 
cond ( va 1  of bo  1  1  ( f a  1 se ( ) , ml , m2) )  =  m2 ; 
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Properties 

exq (of f st ( i , r ) , m, q)  = 

prog(nextmemaddr(m) , 
storer ( 

va 1  of memaddr ( 
i . atomof m 
r,q) ) ; 
exq( 1  ink ( r, n)m, q)  = 

prog(nextmemaddr(m) , 
storer ( 

va 1  of memaddr ( 
r , storem ( fete 
startmema 
exq(un I  ink ( r ) , m, q)  = 

prog(nextmemaddr (m) , 
1 f  ree ( 

getmemi  d (atom 
storer ( 

f etchm (at 
r,q>>>; 
exq (monads ( o, rl ), m, q)  = 


of f set( 
emaddr(fetchr(r,q) ) ) ), 


startmema ddr( lal 1 oc (n, q) ) ) , 
hr ( r, q  )  , 
ddr(lalloc(n,q),q)))); 


ofmemaddr(fetch(r, q) ) )  , 
omofmemaddr (fetchr (  r , q) , q) , 


prog(nextmemaddr(m) 


storer (appl ymo 
rl,q)>; 

exq(monad(o, rl, r2) ,m,q) 

prog(nextmemaddr(m) 

storer (appl ymop 

r2,q)) ; 

exq(monadi (o, v, rl) ,m,q) 

prog(nextmemaddr (m) 

storer (appl ymop 

exq(dyads(o, rl, r2) ,m,q) 

prog(nextmemaddr(m) 

storer (applydop 

o, fetchr ( r 1 

exq ( dyads  i(o,v,rl)m,q) 

prog(nextmemaddr (m) , 
store(applydop(v 
exq(dyad (o, rl , r2, r3) , m, q 
prog(nextmemaddr(m) 
storer (applydop 
fetchr ( r 1 , q 
exq(dyadi (o,v, rl, r2) ,m, 
prog(nextmemaddr(m) 
storer (applydop 

v, fetchr ( r 1 , q 

exq(triads (o, rl, r2, r3) ,m, 

prog(nextmemaddr(m) , 

storer(applytop(o 

fetchr ( r2, q) , 

exq(triadsi (o, v, rl , r2) , m, 
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o, fetchr ( rl , q) ) , 


o, fetchr ( r 1 , q) ) , 


o,v)),rl,q)); 


q),fetchr(r2,q)),r2,q)) ; 


fetchr(rl,q) ) , rl,q) ) ; 
q)  = 


fetch r(r2,q)),r3,q)>; 


m,  q)  = 


)),r2,q)); 
q)  = 

, fetchr ( r 1 , q ) , 
fetchr(r3,q) ) , r3,q) ) ; 
q)  = 


prog (nextmemaddr (m ) 
sto 


op 

q 


exq  ( 


exq  ( 


exq( 


tr iad ( o 

prog ( ne 

sto 

tr  iadi ( 

prog ( ne 

sto 

quads ( o 

prog (ne 

sto 


rer (app 1 y t 
f etchr ( rl . 
, rl, r2, r3, r4 
x tmemaddr (m) 
rer (app 1 y to 
f etchr (r2, 
o,  v,  rl, r2, r 
x tmemaddr (m 
rer (appl yto 
f etchr ( r 1 , 
, r 1 , r2, r3, r 
x tmemaddr (m 


u,  v, 

, f etchr (r2, q) ) , r2, q) ) j 

,m, q)  = 


p(o,fetchr(rl,q), 
q),fetchr(r3,q)),r4,q)) 
m,q)  = 


3 

) 
P 

q 

r4 


exq  ( 


quad ( o, 

prog (ne 

sto 


exq  ( 


exq  ( 


exq  ( 


sexads ( 

prog (ne 

sto 


sexad ( o 

prog (ne 

sto 


octads ( 

prog ( ne 

sto 


exq  ( 


octad ( o 

prog (ne 

sto 


exq  ( 
exq  ( 


m  o  v  i  _m  ( 
prog ( ne 
sto 
mov  i_pc 
prog (ne 


xtmemaddr (m ) 

rer (app 1 yqop 

f etchr ( r2, q 

f etchr ( r4, q 

o, rl , r2, r3, r 

xtmemaddr (m) 

rer (app 1 yqop 

f etchr ( r2, q 

f etchr ( r4, q 

f etch(r6, q) 

, rl , r2, r3, r4 

xtmemaddr (m) 

rer (app 1 yqop 

f etchr ( r2, q 

f etchr ( r4, q 

f etch(r6, q) , 

o, rl , r2, r3, r4 

xtmemaddr (m) 

rer ( app 1 yqop 

f etchr ( r2, q 

f etchr ( r4, q 

fetch ( r6, q ) 

f etchr ( r8, q 

, rl, r2, r3, r4 

xtmemaddr ( m) 

rer (app 1 yqop 

f etchr ( r2, q 

f etchr ( r4, q 

f etch(r6, q) 

f etchr ( r8, q 

v  ,  ml ) , m, q )  = 

xtmemaddr ( m) 

rem ( v , ml , q  )  )  , 

r(v,i),m,q)  = 

xtmemaddr (m ) , 


o,  v 


o,  v, 

, f etchr (r2, q) ) , r3, q) ) ; 

,m,q)  = 


o, f etchr ( r 1 , q) , 

, f etchr ( r3, q ) , 
.  ,  r5, q)  )  ; 
4,  r5, r6) , m, q)  = 

o, f etchr ( r 1 , q 
, f etchr (r3, q) 
, f etchr ( r5, q ) 
r6,q) ) ; 
r5,  r6, r7) , m, q 

o, f etchr ( r 1 , q 

, f etchr ( r3, q ) 

, f etchr ( r5, q) 

r7,q)) ; 

,  r5  ,  r6 , r7, r8) , m, q)  = 

o, f etchr ( r 1 ,  q 
, f etchr (r3t  q) 
, f etchr ( r5, q ) 
f etchr ( r7, q ) , 
,r8,q) ) ; 
r5,  r6, r7, r8, r9 ) , 

o,  f etchr ( r 1 , q ) , 
,  f etchr ( r3, q) , 
,  f etchr ( r5, q ) , 
f etchr (r7, q) , 
,r9,q)) ; 


m 


q)  = 
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storem(v,offset(i,ra),q) ) ; 
exq(movi_r(v,r),rn,q)  = 

prog(nextmemaddr(rn)  , 
storem (  v,  r , q)  )  ; 
exq (movi_r  i ( v , r ) , m, q)  = 
prog(nextmemaddr(m) , 

storem( v, atomof memaddr ( f etchr ( r , q) , q) ) ; 
exq (movi_r id ( vf r ,  n) , m,  q)  = 
prog(nextmemaddr(m) , 
storem(v, offset ( 

n,atomofmemaddr(fetchr(r,q)  ,q) ) ; 
exq(movi_r  idn( v, r,  i 1 ,  i2) , m, q)  = 
prog(nextmemaddr(m) , 

storem(v,offset(i2,  indi  r ( 
il,atomofmemaddr(fetchr(r,q),q) )  ; 

exq (mov_m_m (ml , m2) , m, q)  = 
prog(nextmemaddr (m) , 

storem(fetchm(ml,q) ,m2,q) ) ; 
exq <mov_m_r (ml ,  r )  ,  m,  q )  = 
prog(nextmemaddr(m) , 

storem(fetchm(ml, q) , r, q) ) ; 
q(mov_m_ri(ml,r),m,q)  = 
prog(nextmemaddr(m) , 

storem(fetchm(ml, q) , 
atomofmemaddr(fetchr(r, q)  ,  q) ) ; 
exq(mov_m_r i d (ml ,  r,  n)  ,  m,  q)  = 
prog(nextmemaddr(m) , 


ex 


exq 


prog(nextmemaddr(m) , 

storem(fetchm(ml, q) , offset( 
n,  atomofmemaddr(fetchr(r,  q)  ,  q) ) ; 
(mov_m_r idn (ml , r , i 1 , i2) , m, q)  = 

prog(nextmemaddr(m) , 

storem(fetchm(ml,q),offset(i2,indir( 
il,atomofmemaddr(fetchr(r,q),q) ) ; 

exq (mov_pcr_pcr ( i 1 ,  i2) , m, q)  = 
prog(nextmemaddr (m) , 

5 tor em (f etchm ( of f set ( il , m) , q) , 
of f set ( i2, m) , q) )  ; 
e  x  q ( m  o  v  _p  c  r  _r  (il,r),m,q)  = 
prog(nextmemaddr (m) , 

storem(fetchm(offset(il,m),q), r  ,  q ) ) ; 
exq (mov_pcr_r i ( i 1 ,  r )  ,  m,  q)  = 
prog(nextmemaddr(m) , 

storem(fetchm(offset(il,m)  ,  q)  , 
atomofmemaddr(fetchr(r,q)  ,q) ) ; 
exq  (mov_pcr__r  id  (  i  1 ,  r  ,  i2)  ,  m,  q)  = 
prog(nextmemaddr(m) , 

storem(fetchm(offset( il , m)  ,  q)  ,  offset( 
i2,atomofmemaddr(fetchr(r,q),q) )  ; 
exq(mov_pcr_ridn(il,r,n, i2) , m, q)  = 
prog(nextmemaddr(m)  , 
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exq(mov 
pro 

exq (mov 
pro 

exq (mov 
pro 

exq (mov 
pro 


exq (mov 
pro 


storem( f etchm (of f set <  i  1 , m) , q) , of f set< 12, 

indir(n,atomofmemaddr(fetchr(r,q),q) ) ; 

_r_m(rl,ml),m,q)  = 
g(nextmemaddr(m) , 

storem(fetchr(rl,q) ,ml,q) ) ; 
_r_pcr ( rl , i ) , m, q)  = 
g(nextmemaddr(m) , 

storem(f etchr (rl, q) , of f set( i ,m) , q) ) ; 
_r_r  ( r 1 , r2) , m, q)  = 
g(nextmemaddr(m) , 

storem(fetchr(rl,q), r2,q) ) ; 
_r_r i ( rl ,  r2)  ,  m,  q)  = 
g(nextmemaddr(m) , 

storem(fetchr(rl, q) , 

atomofmemaddr(fetchr(r2,q),q) ) ; 
_r_rid(rl,r2,n),m,q)  = 
g ( nex tmemaddr (m ) , 


exq (mov 
proj 


exq (mov 
pro 


exq (mov 
pro 


exq (mov 
pro 


exq (mov 
pro 


exq (mov 
pro 


exq (mov 
pro 


;(nextmemaddr(m) , 
storem(fetchr (rl , q) , of f set ( i2, indir ( 
il,atomofmemaddr(fetchr(r2,q),q)); 

_ri_m(rl,ml),m,q)  = 
g ( nex tmemaddr ( m ) , 

storem( fetchm (atomofmemaddr ( fetchr ( rl , q ) , q) , 

ml , q) )  ; 
_ri_pcr ( rl , i ) , m, q)  = 
g(nextmemaddr(m) , 

storem(fetchm(atomofmemaddr (fetchr ( rl , q)  , q)  , 

of  f set  C  i , m) , q) ) ; 
_ri_r(rl,r2),m,q)  = 
g(nextmemaddr(m) , 

storer(fetchm(atomofmemaddr(fetchr(rl,q),q), 

r2,q)) ; 
_ri_ri(rl,r2),m,q)  = 
g(nextmemaddr(m) , 

storem( fetchm (atomofmemaddr (fetchr(rl,q),q), 

atomofmemaddr(fetchr(r2,q)),q)); 
_r  i  _r  id(rl,r2,n),m,q)  = 
g ( nex  tmemaddr ( m ) , 

storem(fetchm(atomofmemaddr(fetchr(rl,q) ,q) , 

offset(n,atomofmemaddr(fetchr(r2,q) ) ,q) ) ; 
_r i_r i dn ( r 1 ,  r2,  i 1 ,  i2) , m, q )  = 
g(nextmemaddr(m) , 

storem( fetchm (atomofmemaddr (fetchr(rl,q),q), 

offset(i2, indir( 

i 1 f  atomofmemaddr (fetchr  Cr2t  q) ) ) ,q) ) ; 


exq (mov_r  id_m( rl,  il,ml),m,q) 
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prog (nextmemaddr (m) , 

storem ( fete hm( offset (il, 

atoinof  memaddr  (  f  etchr  (  r  1 ,  q )  )  )  ,  q)  ,ml,q)  )  ; 
exq(mov_r  id_pcr ( rl , i 1 , i2) , m, q)    = 

prog (nextmemaddr ( m) , 

storem(fetchm(offset( il, 
atomofmemaddr(fetchr(rl,q))),q), 
of f set ( i2, m) , q) ) ; 
exq(mov_r  id_r  ( rl , n, r2) , m, q)  = 

prog (nextmemaddr (m) , 

storer(fetchm(offset(n, 

a tomof memaddr (f etchr (rl,q))),q),r2,q)); 
exq(mov_r id_r i ( rl ,  i  ,  r2)  ,  m,  q)  = 

prog (nextmemaddr (m) , 

storem ( f etchm ( of f set ( i , 
atomofmemaddr(fetchr(rl,q) ) ) ,  q)  , 
atomof memaddr ( f etchr ( r2, q) ) , q) ) ; 
exq(mov_rid_rid(rl,  il , r2, i 1 ) , m, q)  = 

prog (nextmemaddr (m) , 

storem( fete hm( offset ( il, 
a tomof memaddr (fetchr(rl,q) ) ) , q) , 
offset( il, a tomof memaddr (fetchr(r2,q)),q)); 
exq(mov_r id_r  idn(rl,r2,il,i2,i3),m,q)  = 

prog (nextmemaddr (m) , 

storem(fetchm(offset( il, 
atomof memaddr ( f etchr ( r 1 , q ) ) ) ,q) , 
offset(i3, indir( 
i2,atomofmemaddr(fetchr(r2,q) ) ) ) , q) ) ; 


exq(mov_r  idn_m 

prog (nex tm 

storem 

indi  r ( 

f etchr 

exq(mov_ridn_p 

prog (nex tm 

storem 

indi  r ( 

of  f set 

exq(mov_ridn_r 

prog (nex tm 

storer 

indi  r ( 

f etchr 

exq(mov_ridn_r 

prog ( nex tm 

storem 

indi  r ( 

atomof 

exq(mov_ridn_r 

prog (nex tm 

storem 


(rl,n,il,ml),m,q)  = 

emaddr (m) , 

(f etchm(of f set ( i 1 , 

n, atomofmemaddr ( 

(rl,q) ) ) ),q) ,ml,q) ) ; 

cr ( rl , n, i 1 , i2) , m, q)  = 

emaddr ( m) , 

(fetchm(offset( il, 

n, atomofmemaddr (fetchr(rl,q) ) ) ),q), 

( i2, m) , q) ) ; 

( rl, i 1, i2, r2) , m, q)  = 

emaddr ( m) , 

(f etchm (of f set < 12, 

i  1,  atoinof  memaddr  ( 

(rl,q) ) ) ) ,q), r2,q) ) ; 

i ( r 1 ,  i 1 ,  i2, r2) , m, q)  = 

emaddr (m ) , 

(f etchm(of f set ( i2, 

i 1 , atomof memaddr ( f etchr ( rl , q) ) ) ),q), 

memaddr(fetchr(r2,q) ) ,q) ) ; 

id(rl, i 1 , i2, r2, i3) , m, q)  = 

emaddr (m) , 

(fetchm(offset( i2, 
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indir(il,atomofmemaddr(fetchr(rl,q) ) ) ),q), 
offset (  i3, atomof memaddr (fetchr(r2, q) ) , q) ) ; 
exq(mov_ridn_ridn (rl,r2,il,i2,i3,i4),m,q)  = 
prog(nextmemaddr(m) , 

storem(fetchm(offset( i2, 

indir(il,atomofmemaddr(fetchr(rl,q) ) ) )  ,  q  ) , 
of f set ( i4, indir ( 

i3,atomofmemaddr(fetchr(r2,q) ) ) ) ,q) ) ; 
exq ( push_i  ( v, s ) , m, q)  = 
prog(nextmemaddr(m) , 
pushstk ( v , s , q) ) ; 
exq ( push_ra (ml , s ) , m, q)  = 
prog (next memaddr (m) , 

pushstk(fetchm(ml, q) , s, q) ) ; 
exq ( push_pcr ( i , s ) , m, q )  = 
prog (next memaddr (m) , 

pushstk(fetchm(offset(i,m) ,  q) , s, q) ) ; 
exq ( push_r ( r , s ) , m, q )  = 

prog (next memaddr ( m) , 

pushstk(fetchr(r,q), s,q) ) ; 
exq ( push_r i ( r  ,  s ) , m, q)  = 
prog(nextmemaddr(m) , 

pushstk(atomofmemaddr(fetchr(r,q)),s,q)); 
exq ( push_r id ( r , n, s ) , m, q)  = 
prog(nextmemaddr(m) , 

pushstk ( f etchm( of  f set (n, 
atomofmemaddr (fetchr (r, q) ) ) , q) , s , q) ) ; 
exq ( push_r i dn( r  ,  i 1 ,  i2, s ) , m, q)  = 
prog(nextmemaddr(m) , 

pushstk(fetchm(offset( i2, indir( i 1, 
atomofmemaddr (fetchr(r,q) ) ) ) ,q) ,s,q) ) ; 
exq ( pop_x ( s ) , m, q )  = 

prog(nextmemaddr(m) , 
pops tk ( s , q) ) ; 
exq ( pop_m ( s , ml ) , m, q )  = 

prog ( next memaddr (m) , 

popstk(s,  storern(topstk(s,  q)  fmlf  q)  )  )  ; 
exq ( pop_pcr ( s, i ) , m, q )  = 
prog(nextmemaddr(m) , 

popstk(s, storem(topstk(s, q) , 
of  f set (i,m),q))); 
exq ( pop_r ( s , r ) , m, q)  = 

prog(nextmemaddr (m) , 

popstk(s,storer(topstk(s,q), r,q) ) ) ),m,q) ; 
exq ( pop_r i ( s , r ) , m, q)  = 

prog(nextmemaddr(m) , 

popstk(s, storem(topstk(s, q) , 
atomofmemaddr (fetchr (r, q) ) , q) ) ) ; 
exq ( pop_r i d ( s, r , n) , m, q)  = 
prog ( nex tmemaddr (m) , 

popstk(s, storem(topstk(s,q) ,offset(n, 
atomofmemaddr ( fetchr ( r, q) ) ) , q) ) ) ; 
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exq( pop_r  idn( s, 

prog (nextme 
popstk ( 
indi  r ( i 
exq (nop, m, q)  = 

prog (nextme 
exq ( stop, m, q)  = 

prog (ra, q)  = 
exq( jmp (ml ) , m, q 

prog(ml , q)  ; 
exq ( jmp_i  (ml )  , m 

prog (atomof 
exq ( jmp_r ( r ) , m, 

prog (atomof 
exq( bra( n) , m, q) 

prog (offset 
exq( bra_r ( r ) , m, 

prog ( offset 

nex tmemaddr 
exq ( i  f (o, rl , r2, 

prog ( cond (a 

ml , nextmema 
exq (ifi(o,r,v,m 

prog ( cond (a 

ml , nextmema 
exq(ifte(o,rl,r 

prog ( cond (a 

ml , m2) , q) ; 
exq (iftei(o,r,v 

prog (cond (a 


r, i 1 , i2) , m, q)  = 

maddr (m) , 

s,storem(topstk(s,q),offset(i2, 

1 , atomof memaddr ( fetchr ( r, q) ) ) ) , q) ) ) ; 

maddr (m) , q) ; 

q; 

)  = 

,q>  = 

memaddr (fetchm (mly  q) ),q) ; 

q)  = 
memaddr(fetchr(r,q) ),q) ; 

(n, nextmema ddr(m) ) ,q) ; 

q)  = 

(atomofint(fetchr(r,q)), 

(m) ) , q) ; 

ml ) , m, q)  = 

pplyrop(o, fetchr(rl, q) , fetchr (r2, q) ) , 

ddr (m) ) , q) ; 

1 ) , m, q  )  = 

pplyrop(o, fetchr (r, q) , v, 

ddr ( m ) ) , q) ; 

2, ml , m2) , m, q )  = 

pplyrop(o, fetchr(rl, q) , fetchr(r2, q) , 

,  ml , m2) , m, q)  = 
pplyrop(o,fetchr(r,q),v,ml,m2),q); 


exq  (  i  f  _pcr  (  o,  r  1 ,  r2,  n)  ,  m,  q  )  = 

prog(cond(applyrop(o, fetchr(rl,q) , fetchr(r2,q), 

offset(n, nextme ma ddr (m) ) , nextmemaddr(m) ) , q) ; 
exq ( i f i_pcr ( o,  r  ,  v,  n )  ,  m,  q )  = 

prog(cond(applyrop(o, fetchr(r, q) , v) , 

offset(n,nextmemaddr(m)),nextmemaddr(m)),q); 
exq( i f te(o, rl , r2, i 1 , i2) , m, q)  = 

prog(cond(applyrop(o, fetchr(rl, q) , fetchr (r2, q) , 

of f set ( i ly  nextmemaddr (m) ) , 

offset(i2,nextmemaddr(m) ) ) ,q) ; 
exq( i f tei (o, r, v, ml , m2) , m, q )  = 

prog(cond(applyrop(o, fetchr (r, q) , v) , 

offset(il,nextmemaddr(m) ), 

offset(i2,nextmemaddr(m))),q) ; 
exq ( tes t ( o, r 1 , ml ) , m, q)  = 

prog(cond(applybop(o, fetchr (rl,q) ) , 

ml , nextmemaddr (m) ) , q) ; 
exq( testm (o, m2, ml ) , m, q)  = 

prog(cond(applybop(o, fetchm(m2, q) ) , 

ml , nextmemaddr (m) ) ,q) ; 
exq( teste ( o, rl , ml , m2) , m, q)  = 
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prog ( cond (app ly bop (o, fetchr(rl,q) )  , 

ml , m2 ) , q ) ; 
exq ( testme ( o, m3, ml , m2) , m, q)  = 

prog(cond(applybop(o, f etchm ( m3, q) ) , 

ml , m2) , q) ; 
exq ( test_pcr ( o, r 1 , n) , m, q)  = 

prog(cond(applybop(o, fetchr(rl,q) ) ; 

of fset(n, nextmemaddr (m) ) , 

nex  tmernaddr  (m) ) , q ) ; 
exq ( testm_pcr ( o,  m2,  n) , m, q)    = 

prog(cond(applybop(o, fetchm(m2, q) ) ; 

of f set (n, nex tmemaddr (m)  )  , 

nextmemaddr (m) ) , q) ; 
exq ( testejpcr ( o, rl , i 1 , i2) , m, q)  = 

prog(cond(applybop(o, fetchr(rl,q) ) ; 

offset(il,nextmemaddr(m) ), 

offset( i2, nextmemaddr(m) ) ) , q) ; 
exq ( testme_pcr ( o,  m3,  i 1 ,  i2) , m, q)  = 

prog(cond(applybop(o, fetchm(m3,q) ) ; 

offset( i 1 , nextmemaddr(m) ) , 

offset( i2, nextmemaddr(m) ) ) , q) 
exq ( j sr (ml , s ) , m, q )  = 

prog(ml, pushstk( 

valofmemaddr(nextmemaddr(m) ) , s,q) ) ; 
exq(jsr_i(ml,s),m,q)  = 

prog(atomofmemaddr( f etchm (ml , q ) ) , 

pushstk(valofmemaddr(nextmemaddr(m) ) , s,q) ) ; 
exq(jsr_i(rl,s),m,q)  = 

prog ( atomof memaddr  Cf etchr (rl, q) ) , 

pushstk(valofmemaddr (nextmemaddr (m) ) , s , q) ) ; 
exq (bsr (n, s ) , m, q)  = 

prog(offset(n, nextmemaddr (m) ) , 

pushstk(valofmemaddr( nextmemaddr ( m) ) , s , q) ) ; 
exq(bsr_r(r,s),m,q)  = 

prog(offset(atomofint(fetchr(r,q) ) , 

nextmemaddr (m) ) , 

pushs tk (valofmemaddr(nextmemaddr(m) ),s,q) ) ; 
exq (rts(s),m,q)  = 

prog(atomofmemaddr ( topstk (s, q) ) , popstk(s, q) ) ; 
exq ( open ( s ), m, q )  = 

prog(nextmemaddr(m) , openfi le( 

atomofstr.char(topstk(s,popstk(s,popstk(s, 

popstk ( s , q) ) ) ) ) , 
atomoffi le(topstk(s,popstk(s,popstk(s,q)) ) ), 
atomofint(topstk(s, popsstk(s, q) ) ) , 
atomofint(topstk(s, q) , 
popstk ( s , q ) ) ) ; 
exq ( c 1 ose ( s ) , m, q)  = 

prog(nextmemaddr(m),closefile( 
atomoffi le(topstk(s,q) ) , 
popstk ( s , q ) ) ) ; 
exq ( read ( s ), m, q )  = 
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end    am; 
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APPENDIX  B:  COMPLETE  SPECIFICATION  OF  A  SUBSET  OF 
THE  ABSTRACT  PROCESSOR 

Resource  intructions  is 

Extension  of 

natura 1 , 
integer , 
memaddress , 
regaddress , 
stkaddress , 
operatorc lasses, 
intructiontype, 
typing 

Operands 

Operators 

monad:  mop, regaddr , regaddr  ->  instr; 

dyad:  dop, regaddr , regaddr , regaddr  ->  instr; 

triad:  top, regaddr , regaddr , regaddr , regaddr  ->  instr; 

mov_m_r :  memaddr , regaddr  ->  instr; 

mov_r_m:  regaddr , memaddr  ->  instr; 

mov_r_r:  regaddr, regaddr  ->  instr; 

push_r:  regaddr , stkaddr  ->  instr; 

pop_r :  stkaddr , regaddr  ->  instr; 

jmp_r:  regaddr  ->  instr; 

if:  re  1  op, regaddr , regaddr , memaddr  ->  instr; 

jsr:  memaddr , stkaddr  ->  instr; 

rts:  stkaddr  ->  instr; 

Properties 

end  intructions; 


Resource  amstate  is 

Extension  of 

boo  1 ean, 
natura 1 , 
integer , 
str(character) , 
memaddress , 
regaddress , 
f  i  1 es , 

i  dent  i  f  i  er s , 
typing 
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Static 

Operands 

state ; 

Operators 

f etchm: 
f etchr : 
storem: 
storer : 
topstk : 
pushs tk : 
popstk : 
ini tarn: 
ini  tstk  : 


memaddr , state  ->  val; 
regaddr , state  ->  val; 
va 1 , memaddr , state  ->  state; 
va 1 , regaddr , state  ->  state; 
stkaddr, state  ->  val; 

va 1 , stkaddr, state  ->  state; 
stkaddr , state  ->  state; 
->  state; 

stkaddr , state  ->  state; 


active:  memid, state  ->  bool; 


Properties 

topstk ( s , ini  ts 
popstk ( s, ini  ts 
popstk ( s , ini  ta 
stateax  iom (m, m 
stateax  iom ( r , r 
topstk ( s ( push 
popstk ( s ( pushs 
act  i ve (m,  ini  ta 
active (m, store 
act  i ve (m, store 
active (m, ini  ts 
act i  ve (m, pushs 
active (m, popst 
i  f  act i  ve (m, q ) 
then 

f etchm ( off 
endi  f  ; 

i  f  act i  ve (m, q) 
then 

storem ( v , o 
endi  f  ; 

if  1 t  int (n, nto 
then 

offset (n, o 

1  a  1 1 oc 

of  f set 

s tar tm 

e  1  se 

of  f set (n, o 
1  a  1 1 oc 
endi  f  ; 

indi  r ( zeronat ( 
if  whattype(fe 
then 


tk(s))  is  undefined; 
tk(s))  is  undefined; 
m())  is  undefined; 
emaddr ) ; 
egaddr ) ; 

stk ( v, s , q) )  =  v; 
tk ( v, s, q) )  =  q; 
m( ) )  =  false( ) ; 
r(v,r,q))  =  active(m,q); 
m(v,a,q))  =  active(m,q); 
tk(s,q))  =  active(m,q); 
tk(v,s,q)  =  active(m,q); 
k(s,q)  =  active(m,q); 
=  falseO 

set(n,m),q)  is  undefined; 

=  f a  1 se (  )  ; 

f f set (n, m ) , q)  is  undefined; 

i(n2)>  =  trueO 

f f  set (nl , startmemaddr( 
(n2,q) ) ) )  = 
( sumint (n, nl ) , 
emaddr ( lal loc(n2,q) ) ) ; 

f f set ( nl , star t memaddr ( 
(n2,q))))  is  undefined; 

) , m)  =  m ; 

tchm ( ind i r ( n,  m)  ,  q )  =  typememaddr ( ) 
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indi r ( succnat (n) , m )  = 

a torn of memaddr (fetchm(indir(n,m),q) ) ; 
else 

indi r ( succnat (n) , m)  is  undefined; 
endi  f ; 

Dynamic 

Entry  Places 

req_f etchra (netlabel ) [memaddr. state] ; 
req_s tor em (netlabel ) Cval .memaddr.  state] ; 

req_f  etchr (netlabel ) Cregaddr. state] ; 
req_storer (netlabel ) Cval . regaddr. state] ; 

req_topstk (netlabel ) Cstkaddr. state] ; 
req_pushstk (netabel ) Cval , stkaddr. state] ; 
req_popstk (netlabel ) Cstkaddr.  state] ; 
req_initstk(netl abe 1 ) Cstkaddr.  state] ; 

req_ini  tam ( ) C ] 

Exit  Places 

avai l_fetchm(netlabel ) Cval ] ; 
avai 1 _storem (netlabel ) Cstate] ; 

avai l_fetchr(netlabel ) Cval ] ; 
avai 1 _storer (netlabel ) Cstate]  ; 

avai l_topstk(netlabel ) Cval ] ; 
avai 1 _pushs tk (net  1 abe 1 ) C  state ]  ; 
avai l_popstk(netlabel ) Cstate] ; 
avai l_initstk(netlabel ) Cstate] ; 

avai l_initamCstate] ; 

Internal  Places 

access_avai 1 C ] ; 

fetchm_for(netlabel ) C ]  ; 

f etchm_act  i  vated  C memaddr  .  state ]  ; 

f etchm_comp letedCval ] ; 

storem_f or (netlabel ) C ]  ; 

storem_act i  vatedCval . memaddr. state] ; 

storem_comp letedCstate] ; 

access_avai 1 C ] ; 

fetchr_for(netlabel ) C ] ; 

f e t c h r _a ctivatedCregaddr.  state] ; 

f  e  t  c  h  r  _c  ompletedCval]; 

storer_for (netlabel ) C ] ; 

storer_acti vated  Cval . regaddr. state] ; 

storer_comp 1 eted C state ] ; 
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accessk_avai 1 C ] ; 

tops tk_f or (net  label ) C ] ; 

topstk_acti vatedC  stkaddr .state] ; 

topstk_comp 1 eted C va 1 ] ; 

pushstk_for(netlabel ) C ] ; 

pushstk_acti vatedC  val . stkaddr. state] ; 

pushstk_comp letedCstate] ; 

popstk_f  or (net  1 abe 1 ) C ] ; 

popstk_act i vatedC stkaddr. state]; 

popstk_comp 1 eted C state ] ; 

initstk_for( net  label ) C ] ; 

ini  tstk_acti vatedC  stkaddr.  state]; 

ini  tstk_comp letedCstate] ; 


Initial  State 

=>  accessm_avai 1 C ] ; 

=>  accessr_avai 1 C ] ; 
=>  accessk_avai 1 C ] ; 

Transitions 

act_fetchm:  C memaddr . state ], C ]  ->  Cmemaddr . state ], C ] ; 
perf orm_f etchm :  Cmemaddr . state ]  ->  C va 1 ] ; 
f inish_f etchm :  Cval],C]  ->  Cval],C]; 
act_storem:  C va 1 . memaddr. state ], C ]  -> 

Cval .memaddr. state] , C ] ; 
perf orm_s torem :  C va 1 . memaddr . state ]  ->  Cstate]; 
f ini sh_s torem :  Cstate], C]  ->  Cstate], C]; 

act_fetchr:  C regaddr . state ], C ]  -> 

Cregaddr. state] , C ] ; 
perf orm_f etchr :  C regaddr . state ]  ->  Cval]; 
f inish_f etchr :  [val], £]  ->  Cval],C]; 
act_storer:  C va 1 . regaddr. state ], C ]  -> 

Cval . regaddr. state], C ] ; 
perf orm_s torer :  C va 1 . regaddr . state ]  ->  Cstate]; 
f inish_storer :  Cstate], C]  ->  Cstate], C]; 

act_topstk:  C stkaddr . state] , C ]  -> 

Cstkaddr. state] , C ] ; 
perf orm_tops tk :  C stkaddr . state ]  ->  Cval]; 
f ini sh_topstk :  Cval], []  ->  Cval],C]; 
act_pushstk:  C va 1 . stkaddr . state ], C ]  -> 

Cval . stkaddr. state] , C ] ; 
perf orm_pushs tk :  C va 1 . stkaddr . state ]  ->  Cstate]; 
f inish_pushstk :  Cstate], C]  ->  Cstate], C]; 
act_popstk:  [ stkaddr . state] , C ]  -> 

Cstkaddr. state], C] ; 
perf orm_pops tk :  C stkaddr . state ]  ->  Cstate]; 
f inish_popstk :  Cstate], C]  ->  Cstate], C]; 
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act_initstk:  C stkaddr . state] , C ]  -> 

Cstkaddr. state] , C ] ; 
perf orm_ini ts tk :  [ stkaddr . state ]  ->  Estate]; 
f inish_ini tstk :  [state], []  ->  [state], []; 

perf orm_ini tam :  []  ->  [state]; 

Properties 

act_f  etchm ( req_f  etchm ( 1 ) [m. q] ,  accessm_avai 1 [ ] )  => 

f etchm_f or ( 1 ) [ ] , f etchm_acti vated [m. q ] ; 
pe rform_f etchm ( fetchm_acti vated [m. q] )  => 

f etchm_comp 1 eted[ v ]  ; 
f  ini  sh_f etchm ( f etch_comp 1 eted [ v ]  ,  fetchm_for(l)[]) 

=  >  avai 1 _f etchm ( 1 ) [v ] ,  accessm_avai 1 [ ] ; 
act_s torem ( req_storem ( 1 ) [ v. m. q] ,  accessm_avai 1 [ ] )  => 

storem_for( 1 ) [ ] ,  s torem_act  ivatedCv.m.ql; 
perf orm_s torem ( s torem_act i  vated C v. m. q] )  => 

s torem_comp 1 eted [ q] ; 
f  ini  sh_s torem ( s torem_comp 1 eted [ q] , 

s torem_f or ( 1 ) [ ] )  => 

avai l_storem( 1 ) [q],  accessm_avai 1 [ ] ; 

act_f etchr ( req_f etchr ( 1 ) [ . q] ,  accessr_avai 1 [ ] )  => 

fetchr_for ( 1 ) [ ] ,  fetchr_activated[  .  q] ; 
perform_f etchr ( f etchr _acti  vated[.q])  => 

fetchr_completed[v] ; 
f  in ish_f etchr ( f etch_comp 1 eted [ v ] ,  fetchr_for(l)[]) 

=  >  avail_fetchr(l)[v],  accessr _a v a i 1 [ ] ; 
act_storer(req_storer( I ) [v. . q] ,  accessr_avai 1 [ ] ) 

=  >  storer_f or ( 1 ) [ ] ,  storer_acti vated [ v .. q ] ; 
perf orm_s tor er ( storer_acti vated [ v.  .  q ] )  => 

s  t  o  r  e  r  _c  ompleted[q] ; 
finish _storer( s torer_comp I etedCq] , 

storer_for(l)[])  =>  avail_storer(l)[q], 

accessr_avai 1 [ ] ; 


act_tops tk 

topstk 
per f orm_to 

topstk 
f  ini  sh_top 

avai 1 _ 
act_pushst 

=  >  pus 
perf orm_pu 

pushs t 
f  ini  sh_pus 

=  >  ava 
act_pops tk 

popstk 
perf orm_po 

popstk 


( req_tops tk ( 1 ) [ s . q ]  ,  accessk_ava i 1 [ ] )  => 

_for(l)[],  topstk  _a  ctivated[s.q]; 

pstk(topstk  _a  ctivated[s.q])  => 

_comp 1 eted [ v ] ; 

stk(topstk  _c  ompletedEv],  topstk _for(l)[]  => 

topstkC 1 ) [v] ; 

k  (  reqjushs  tk  (  1  )  [  v  .  s  .  q  ]  ,     accessk_avai  1  [  ]  ) 

hstk_for(l)[],  pushs tk_act  ivated[v. s. q] ; 

shs tk ( pushs tk_acti vated [ s  .  q ] )  => 

k_comp 1 etedCql ]  ; 

hs tk ( pushs tk_comp leted[ql],pushstk_for( 1 ) [ ] 

i l_pushstk( 1 ) [ql] ; 

( req_pops tk ( 1 ) [ s . q] ,  accessk_avai 1 [ ] )  => 

_for(  1  )  [  ],  popstk _activated[s.  q] ; 

pstk(popstk  _a  ctivatedCs.q] )  => 

_comp 1 eted [ ql ] ; 
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f  inish_popstk(popstk_compl etedCql],popstk_for(l)C]  => 

avai 1 _popstk ( 1 ) Cql 1 ; 
act_ini tstk ( req_ini tstk ( 1 )[ s.  q] ,  accessk_avai 1 [ ] )  => 

initstk_for( 1 ) C  3 ,  initstk_activated[s.q] ; 
perf orm_ini tstk(initstk_activatedCs.q])  => 

ini  tstk_comp letedCql]; 
f inish_ini  tstk  (  ini  tstk_compl etedtql 3  ,  ini tstk_f or ( 1 ) C ] 

=  >  avai 1  _ini tstk ( 1 )[ ql 3 ; 

perf orm_ini tarn ( req_ini tamC 3 )  =>  avai l_ini tamC state ] ; 
end  amstate; 

Resource  am  is 

Extension  of 

memaddress , 
intructiontype, 
typing, 
amstate 


Operands 

prog:  memaddr , state  ->  state; 

cond :  va 1 , memaddr , memaddr  -  memaddr; 
exq:  ins tr , memaddr , state  ->  state; 

Operators 

prog(m,q)  =  exq(atomof instr ( f etchm (m, q) ) , m, q) ; 
cond (va 1  of boo  1  ( true (), m, m2) )  =  m; 
cond ( val of bol 1 ( f al se ( ) , m, m2) )  =  m2 ; 

Properties 

exq (monad ( o, r , r2) , m, q)  = 
prog(nextmemaddr(m) , 

storer(applymop(o, f etchr (r , q) ), 
r2,q)); 
exq (dyad ( o, r , r2, r3) , m, q)  = 
prog(nextmemaddr(m) , 

storer(applydop(o, 

f etchr ( r,q), fetchr(r2,q) ) , r3,q) ) ; 
exq( triad(o, r, r2, r3, r4) , m, q)  = 
prog (next memaddr(m) , 

storer(applytop(o, f etchr (r, q) , 

f etchr (r2, q) , f etchr (r3, q) ) , r4, q) ) ; 
exq (mov_m_r (m,  r )  ,  m,  q)  = 
prog(nextmemaddr(m) , 

storem(fetchm(m,q),r,q)) ; 
exq(mov_r_m(r,m),m,q)  = 
prog(nextmemaddr(m) , 

storem(fetchr(r,q),m,q) ) ; 
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Dynamic 

Entry  Places 

req_prog  Cmemaddr. state] ; 

req_exq (netlabel ) [instr.memaddr. state] ; 

req_cond (netlabel  ) Cval .memaddr.memaddr]  ; 

Exit  Places 

avai 1 _exq (netlabel ) Cmemaddr. state] ; 

avai 1 _cond (netlabel ) Cmemaddr] ; 

Internal  Places 

prog_avai 1 C ] ; 

prog _f etch  Cmemaddr. state] ; 
prog_instrCmemaddr. state] ; 
prog_per  f ormC ] 

exq_ava  i 1 C ] ; 
exq_for(netlabel ) C ] ; 

exq_monad_act i vated  C  state] ; 
exq_monad_f etch  C  state ] ; 
exq_monad_app lyCstate] ; 
exq_monad_s tore C ] ; 

exq_dyad_act i  vatedCstate] ; 
exq_dyad_fetchC state] ; 
exq_dyad_app 1 y C state ] ; 
exq_dyad_s tore C ] ; 
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exq_tr iad_act i vatedC state ] ; 
exq_triad_f etchC  state] ; 
exq_tr  iad_appl yC  state] ; 
exq_triad_storeC ] ; 

exq_mov_r_r_act i vatedCstate] ; 
exq_raov_r_r_perf ormC state] ; 
exq_mov_r_r_storeC ]  ; 

exq_mov_r_m_act i vated [ state ] ; 
exq_mov_r_m_perf ormC state] ; 
exq_mov_r_m_store [ ] ; 

exq_mov_m_r_act i  vatedCstate] ; 
exq_mov_m__r_perf  orm  [state  ]  ; 
exq_mov_m_r_store C ] ; 

exqjpush_r_act i vated [state ] ; 
exq_push_r_perform[ state ] ; 
exq_push_r_push[ ] ; 

exq_pop_r_act i vatedCstate] ; 
exq_pop_r_perform[ state ] ; 
exq_pop_r_store [ ] ; 
exq_pop_r_pop[ ] ; 

exq_jmp_r_act i vatedCstate] ; 
exq_jmp_r_perf orm [state ] ; 
exq_jmp_r_conver t ing [ state ] ; 

exq_if_activated[state] ; 
exq_i f_fetch[ state ] ; 
exq_i  f_cond[state] ; 

cond_acti vated [memaddr . memaddr ] ; 

Initial  State 

=  >  prog_avai 1  [  ] ; 

=  >  exq_avai  1  [  ]  ; 

=  >  cond_avai  1  [  ]  ; 

Transitions 

act i vate_prog :  [], [memaddr . state ]  -> 

[memaddr.  state],  [memaddr. state] ; 
get_instr_prog:  [memaddr. state] , Cval ] 

[memaddr. state] , Cval ] ; 
perf orm_prog :  [memaddr . state ] , [instr] 

[], [instr. memaddr. state]; 
finish_prog:  C ], C memaddr . state ]  -> 

C  ] ,  [memaddr. state] ; 


-> 
-> 
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act i vate_exq_monad :  [ instr . memaddr . state ], C ]  -> 

Estate], C  instr 1 ,  Cinstr], [instr ] , [memaddr]; 
start_exq_monad :  [ state] ,[ regaddr ] ,  -> 

[state], [regaddr. state] ; 
aPP 1 y_exq_monad :  [ state] , [operator ],[ va 1 ]  -> 

[state] , [operator. val ] ; 
s tore_exq_monad :  [ state ],[ va 1 ],[ operator ]  -> 

[  ]  , [val . regaddr. state] ; 
f ini sh_exq_monad :  [],[ state ], [memaddr ]  -> 

[memaddr. state] ; 

act i vate_exq_dyad :  [ instr . memaddr . state ],[ ]  -> 

[state], [instr], [instr], [instr], [instr], [memaddr]; 
start_exq_dyad :  [ state] ,[ regaddr ],[ regaddr ]  -> 

[state] , [regaddr. state] , [regaddr. state] ; 
aPP 1 y_exq_dyad :  [ state ],[ operator ],[ va 1 ],[ va 1 ]  -> 

[state], [operator. val , val ] ; 
s tore_exq_dyad :  [ state ],[ va 1 ],[ regaddr ]  -> 

[  ]  ,  [val . regaddr. state] ; 
f ini sh_exq_dyad :  [],[ state ], [memaddr ]  -> 

[memaddr . state ] ; 

act i vate_exq_tr iad :  [ ins tr . memaddr . state ],[ ]  -> 

[state], [instr], [instr], [instr], [instr], 

[ instr] , [memaddr] ; 
star t_exq_tr iad :  [ state ],[ regaddr ],[ regaddr ],[ regaddr ]  -> 

[state], [regaddr. state], [regaddr], [regaddr] ; 
app 1 y_exq_tr iad :  [ state ],[ operator ],[ va 1 ],[ va 1 ],[ va 1 ]  -> 

[state] , [operator. val . val . val ] ; 
store_exq_tr iad :  [ state ],[ va 1 ],[ regaddr ]  -> 

[  ]  ,  [val . regaddr. state] ; 
f ini sh_exq_tr iad :  [],[ state  ],  [memaddr ]  -> 

[memaddr. state] : 


act i vate_exq_mov_r_r :  [ instr. memaddr. state], [] 

[state], [instr], [instr], [memaddr]; 
star t_exq_mov_r_r :  [start], [regaddr]  -> 

[state] , [regaddr. state] ; 
store_exq_mov_r_r :  [ state ],[ regaddr ],[ va 1 ]  -> 

[  ],  [val . regaddr. state] ; 
f ini sh_exq_mov_r_r :  [],[ state  ],[ memaddr ]  -> 

[memaddr. state] ; 


-> 


act i vate_exq_mov_r_m :  [instr. memaddr. state], [] 

[state], [instr], [instr], [memaddr] ; 
s tar t_exq_mov_r_m :  [ star t ],[ regaddr ]  -> 

[state], [regaddr. state] ; 
store_exq_mov_r_m :  [ state ], [memaddr ],[ va 1 ]  -> 

[ ] , [ va 1 . memaddr . state ] ; 
f ini sh_exq_mov_r_m :  [],[ state ], [memaddr ]  -> 

[memaddr. state] ; 


-> 
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act i vate_exq_mov_m_r :  [ instr. memaddr. state ], C ]  -> 

[state], Cinstr], [instr], [memaddr] ; 
s tart_exq_mov_m_r :  [ star t ], [memaddr ]  -> 

[state], [regaddr. state] ; 
store_exq_mov_m_r :  [ state ],[ regaddr ],[ va 1 ]  -> 

[], [val. regaddr. state] ; 
f ini sh_exq_mov_m_r :  [],[ state ], [memaddr ]  -> 

[memaddr. state]  ; 

act i vate_exq_push_r :  [ instr . memaddr . state ],[ ]  -> 

[state], [ instr], [ inestr ] , [memaddr] ; 
f  etch_exq__push_r  :  [  state  1,1  regaddr  ]  -> 

[state], [regaddr. state] ; 
push_exq_push_r :  [ state ],[ va 1 ],[ stkaddr ]  -> 

[ ] , [stkaddr. state]  ; 
f inish_exq_push_r :  [],[ state ], [memaddr ]  -> 

[memaddr. state]  ; 


act i vate_exq_pop_r :  [ instr. memaddr. state], [ ] 

[state] ,  [ instr] , [ instr] , [memaddr]  ; 
pop_exq_pop_r :  [ state ],[ stkaddr ]  -> 

[state] , [stkaddr. state] ; 
store_exq_pop_r :  [ state ],[ va 1 ],[ regaddr ]  -> 

[stkaddr], [stkaddr. state]; 
top_exq_pop_r :  C stkaddr ], C state]  -> 

[ ] ,  [stkaddr. state]  ; 
f ini sh_exq_pop_r :  [],[ state ],[ memaddr ]  -> 

[memaddr. state]  ; 


-> 


act  i vate_exq_jmp_r ([instr. memaddr. state],  []) 

[ state ],[ instr  ]  ; 
fetch_exq_jmp_r ([ state ] , [regaddr]  -> 

[state], [regaddr. state] ; 
convert_exq_jmp_r ([state],  [val])  -> 

[ state ] , [ va 1 ] ; 
f ini sh ([ state  3 , [memaddr 3 )  -> 

[memaddr. state]  ; 


-> 


act  i  vate_cond ( [ 3 ,  [val. memaddr. memaddr])  -> 

[memaddr.memaddr3, [val 3 ; 
f  ini  sh_cond ([memaddr.memaddr3,[bool3)  -> 

[ memaddr  3 ; 

acti vate_exq_i  f([3,  [instr. memaddr. state3)  -> 

[3,  [ state  3 ,  [ ins tr  3 ,  C  instr  3 ,  [instr],  [memaddr]; 
start_exq_if ( [state], [regaddr], [regaddr] )  -> 

[regaddr. state], [regaddr. state]; 
aPP 1 y_exq_i  f ([state],  [val],  [val],  [operator])  -> 

[state] , [operator. val . val ] ; 
cond_exq_i  f ([state],  [memaddr],  [val],  [memaddr])  -> 

[state], [val .memaddr. memaddr ] ; 
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f ini sh_exq_i  f ([ state ] ,  [memaddr]  -> 
C  memaddr . state  3 ; 

Properties 

act i vate_prog (prog_avai 1 [ 3 ,  req_prog Cm. q ] )  => 

prog_f etchCm.  q],  req_fetchm(ll)Cm.q3; 
get_instr_prog(prog_activatedCm. q] ,  avai l_fetchm( 1 1 ) Cv] ) 

=  >  prog_ins tr Cm.  q3 ,  req_atomof ins tr ( 1 2) [ v 3 ; 
perf orm_prog (prog_instrCm.  q]  , 

avai 1 _atomof instr ( 1 2) C i ] )  => 

prog_perf ormC ] ,  req_exq (13)Ci.m.q3; 
f inish_prog ( prog_perform[  3  ,  avai 1 _exqCml .  ql ] )  => 

prog_avai 1 C ] ,  req_prog Cml .  ql 3  ; 

act i vate_exq_monad (exq_avai 1 C  3 , 

req_exq ( 1 ) C monad (o.rl.r2).m.q3)  => 

exq_for( 1 ) C  3 ,  exq_monad_activated[q3 , 

req_operator ( 11) [monad ( o.  ri .  r2) 3, 

req_operandl( 12) Cmonad(o. rl. r2) 3, 

req_operand2( 13) [monad(o. rl. r2) 3 , 

req_nex  tmemaddr ( 14) Cm3 ; 
start_exq_monad (exq_monad_activatedCq3, 

avai 1 _operandl ( 1 1 )  [  rl 3 )  ->  exq_monad_f etchC q 3 , 

req_f etchr ( 1 5 ) [ rl . q3 ; 
apply_exq_monad(exq_monad_fetch[q3,  avai l_fetchr( 15) Cv3, 

avai 1 _operator ( 1 1 ) [ o 3 )  =>  exq_monad_app 1 y C q3 , 

req_app 1 y_mop ( 1 6 ) C  o .  v  3 ; 
store_exq_monad ( exq_monad_app 1 y [ q  3 , 

avai 1 _app 1 y_mop ( 1 6 ) C vl 3 ,  avai 1 _operand2 ( 1 3) C r2 3 )  => 

exq_monad_s tore  [  3  ,  req_storer(17)Cvl.r2.q3; 
f  ini  sh_exq_monad ( exq_monad_s toreC  3,  avail_storer(17)[ql3, 

avai 1 _nex tmemaddr ( 1 4) [ml  3 )  =>  avai 1 _exq ( 1 ) Cml . ql 3 ; 

act i  vate_exq_dyad ( exq_avai 1  [ 3  , 

req_exq( 1 ) Cdyad(o. rl. r2, r3)  .m.  q3 )  => 

exq_f or ( 1 ) C  3  ,  exq_dyad_act i vated [ q  3  , 

req_operator ( 11) [dyad(o. rl. r2, r3) 3, 

req_operandl ( 12) Cdyad(o. rl. r2, r3) 3, 

req_operand2( 13) [ dyad ( o . rl. r2, r3) 3 , 

req_operand3< 18) Cdyad(o. rl. r2,  r3) 3, 

req_nex tmemaddr ( 14) Cm] ; 
s tar t_exq_dyad ( exq_dyad_act i vatedCq] , 

avai l_operandl ( 1 1 ) [rl 3 ) ,  avai l_operand2( 12) Cr2  3 

->  exq_dyad_fetch[q3, req_f etchr ( 15) [ rl . q3 

req_f etch( 19) [ r2.  q3 ; 
aPP 1 y_exq_dyad (exq_dyad_fetch[q3,  avai l_fetchr( 15) [  vl  3  , 

avai l_operator( 1 1 ) [o3 ) ,avai l_fetchr( 19) [v23 
=>  exq_dyad_apply[q3 , req_apply_dop( 16) Co. vl . v23 ; 
store _exq_dyad( exq_dyad_app 1 y [ q3  , 

avai l_apply_dop( 16) [ v33 ,  avai 1 _operand3 ( 1 8) [ r3 3 )  => 

exq_dyad_store[ 3  ,  req_storer(  17) [v3. r3. q3 ; 
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f inish_exq_dyad ( exq_dyad_storeC ],  avail_storer(17)Cql], 
avai l_nextmemaddr ( 14) Cml ] )  =>  avai 1 _exq ( 1 ) [ml . ql ] ; 

act i vate_exq_tr iad (exq_avai 1 C ] , 

req_exq( l)Ctriad(o.rl.r2,r3,r4).m.q])  => 

exq_f or (  1  ) C ] ,  exq_tr  iad_activated[q]  , 

req_operator ( 1 1 ) C triad (o.  r 1.  r2,  r3) ] , 

req_operandl (12)Ctriad(o.rl.r2,r3)], 

req_operand2( 13)Ctriad(o.rl.r2,r3)], 

req_operand3(  18)  C  triad  <o.  rl .  r2,  p"3)  ]  , 

req_operand4 ( 1 10) Ctriad(o. rl.  r2,  r3,  r4) ] , 

req_nex tmemaddr ( 14) Cm] ; 
start_exq_tr iad ( exq_tr  iad_act i vated C  q ] , 

avail_operandl(ll)Crl]),avail _operand2( 12) C  r2] 

avai 1  _o  per and 3 ( 1 3) C  r3  3 , ->  exq_tr  iad_fetchCq], 

req_f  etchr( 15) Crl. q], req_f etch( 19) Cr2. q] , 

req_f etchr( 1 11 ) Cr3.  q] ; 
app 1 y_exq_tr  iad (exq_tr  iad_fetchCq],  avai l_fetchr( 15) C  vl  ]  , 

avai l_operator( 1 1) Co] ) ,avai l_fetchr( 19) Cv2]  , 

avai 1  _f  etchr ( 1 1 1 ) C v3]  =>  exq_tr iad_app 1 y C q ]  , 

req_apply_top( 16) Co.  vl.  v2.  v3] ; 
store_exq_tr  iad (exq_tr  iad_applyCq] , 
avai l_apply_top( 16) C v4]  ,  avai 1 _operand4 ( 1 8) C r4 ] )  => 

exq_tr  iad_storeC ] ,  req_storer (17)Cv4.r4.q]; 
f  inish_exq_tr  iad ( exq_tr  iad_storeC ]  ,  avai l_storer ( 17) Cql ] , 

avai 1 _nex tmemaddr ( 1 4) Cml ] )  =>  avai 1 _exq ( 1 ) Cml . ql ] ; 


act i  vate 
r 

e 


ate_exq_mov_r_r ( exq_avai 1 C ] , 
eq_exq (l)Cmov_r_r(rl,r2).m.q])  => 
xq_mov_r_r_act  ivatedCq] , 

req_operandl ( 11) Cmov_r_r(rl,  r2) ], 

req_operand2( 12) Cmov_r_r(rl,  r2) 3 , 

req_nextmemaddr( 13) Cm] ; 
tar t_exq_mov_r_r ( exq_mov_r_r_act  ivatedCq] , 

avai 1 _operandl ( 1 1 ) C r 1 ] )  => 

exq_mov.  r * r  "  "■   '-*■  ~w-  '  '  '-  s  r 


avai l_exq( 1 ) Cml. ql ] ; 

act i vate_exq_mov_r_m (exq_avai 1 C ]  , 

req_exq ( 1 ) C  mov_r_m (rl,m2).m.q])  = 

e x q_m ov_r _m_a ctivatedCq]  , 

req  operandi ( 1 1 ) Cmov  r  m(rl,m2)], 


star 
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store_exq_mov_r_m  (  exq_mov_r_m_perf ormCq  ] , 

avai l_fetchr ( 14) C v3 ,  avai 1 _operand2( 1 2) Cm23 )  => 
exq_mov_r_m_storeC  3 ,  req_s toremC  v.  m2. q ] ; 

f  ini  sh_exq_mov_r_m ( exq_mov_r_m_store C  3 ,  avai 1 _storemC  ql ] , 
avai 1 _nex tmemaddr ( 1 3) Cml ] )  => 
avai l_exq(l)Cml.ql3; 

act i vate_exq_mov_m_r (exq_avai 1 [ ] , 

req_exq ( 1 ) [mov_m_r (m2, r2) . m. q] )  => 

exq_mov_m_r_act i vated  C  q ] , 

req_operandl ( 1 1 ) [mov_m_r (m2,  r2)  3 , 

req_operand2( 1 2) Cmov_m_r  Cm2, r2) 1 , 

req_nex tmemaddr ( 1 3) Cm] ; 
start_exq_mov_m_r ( exq_mov_m_r_act i vated C q ] , 

avai 1 _operandl ( 1 1 ) Cm2] )  => 

exq_mov_m_r_perf ormC q ] ,  req_f etchm ( 1 4 ) Cm2. q  3 ; 
store_exq_mov_m_r ( exq_mov_m_r_perf ormC q]  , 

avai l_f etchm( 1 4) C v3 ,  avai 1 _pperand2 ( 1 2) C r23 )  => 

exq_mov_m_r_store  C ] ,  req_s torer  C  v.  r2.  q ] ; 
f  ini  sh_exq_mov_m_r (exq_mov_m_r_s tore  C  3 ,  avail_storerCql], 

avai 1 _nex tmemaddr ( 1 3) [ ml ] )  => 

avai l_exq( I ) Cmi. ql ] ; 

act i  vate_exq_push_r ( exq_avai 1 C ] , 

req_exq ( 1 ) C push_r ( s  ,  r ) . m.  q ] )  => 

exq_push_r_act i vatedCq], 

req_operandl (ll)Cpush_r(s,r)], 

req_operand2( 12)Cpush_r(s,r)], 

req_nex tmemaddr ( 1 3) C  m ] ; 
f etch_exq_push_r ( exq_push_r_act i vated [ q] , 

avai 1 _operand2 ( I  2 ) C r ] )  => 

exq_push_r_per f orm C  q] ,  req_f etchr ( 1 4 ) C  r  .  q] ; 
push_exq_push_r ( exq_push_r_perf ormC q ] , 

avai 1 _f etchr ( 1 4) [ v ] ,  avai 1 _operandl ( 1 1 ) C s ] )  => 

exq_push_r_s toreC ]  ,  req_pushC  v.  s  .  q  3  ; 
f ini  sh_exq_push_r ( exq_push_r_store  C3,  avail_push[ql3, 

avai 1 _nex tmemaddr ( 1 3 ) C ml  3 )  => 

avai l_exq( 1 ) Cml. ql 3 ; 

act  i vate_exq_pop_r (exq_avai 1 C  3 , 

req_exq ( 1 ) C pop_r ( s , r ) . m. q3 )  => 

exq_pop_r_act i vatedCq3 , 

req_operandl (ll)Cpop_r(s,r)3, 

req_operand2( 12) Cpop_r(s,  r) 3  , 

req_nex tmemaddr ( 1 3) Cm  3 ; 
pop_exq_pop_r ( exq_pop_r_act  ivatedCq3  , 

avail _o  perandl(ll)Cs3)  => 

exq_pop_r_per f ormC q3 ,  req_top( 1 4) C  s. q  3 ; 
store_exq_pop_r ( exq_pop_r_perf ormC  q3  , 

avai 1 _top ( 1 4) C v 3 ,  avai 1 _operand2 ( 1 2) C r 3 )  => 

exq_pop_r_store  Cs3,  req_storerCv.r.q3; 
top_exq_pop_r ( exq_pop_r_s tore  Cs3,avail_storerCql3  => 
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exq_pop_r_pop[ ] ,  req_popCs.  ql ] ; 
f inish_exq_pop_r (exq_pop_r_popC 3 ,  avai 1 _popCq2] , 
avai 1 _nex tmemaddr ( 1 3) [ml ] )  => 
avai 1 _exq ( 1 ) [ml . q2  3 ; 

act i vate_exq_jmp_r (exq_avai 1 [ 3 , 

req_exq ( 1 ) [ jmp( r ) . m. q] )  => 

exq_jmp_r_acti vatedt q] , 

req_operandl C 1 1 ) C jmpCr ) 1 ; 
f etch_exq_jmp_r (exq_jmp_r_act i vatedt q ]  , 

avai l_operandl ( 1 1 ) [ r ]  => 

exq_jmp_r_perf orm[ q  3 , req_f etchr ( 1 2) [ r . q ] ; 
conver t_exq_jmp_r ( exq_jmp_r_perf orm[ q3 , 

avai l_fetchr( 12) [v] )  => 

ex q_jmp_r_con verting [ q] ,  req_atomof memaddr ( 1 3 ) [ v ] ; 
f  inish_exq_jmp_r ( exq_jmp_r_conver t ing [ q ] , 

avai l_atomof memaddr ( 1 3) [ml ]  => 

avai l_exq( 1 ) [ml. q] ; 


act i vate_cond (cond_avai 1 [ 3, req_cond( 1 ) [v.ml.m23 ) 

cond_activated [ml . m2  3 , req_atomof boo  1  ( 1 1 ) [ v  3 ; 
f  inish_cond ( cond_act i vated [ml . m2  3 , 

avai 1 _atomof boo  1 ( 1 1 ) [ true ( ) 3  => 

avai 1 _cond ( 1 ) [ml  3 ; 
f  ini sh_cond (cond_activated[ml . m23 , 

avai 1 _atomof boo  1  ( 1 1 ) [ f a  1 se ( ) 3  => 

avai 1 _cond ( 1 ) [m2  3 ; 


*=> 


act  i vate_e 
req_ex 
exq_f o 
req_op 
req_op 
req_op 
req_ne 

star t_exq_ 

avai l_operandl 

->  exq 

req_f  e 

app 1 y_exq_ 
avai  1  _ 
exq_i  f 

cond_exq_i 
avai  1  _ 
exq_i  f 

f  ini  sh_exq 
avai 1 _ 

end  am; 


xq_i  f (exq_avai 1 [ 3 , 

q( 1 ) [ if (o. rl. r2.ml) .m.q3)  => 

r(l)[3,  exq_i f_acti vated [ q3  , 

erator C 1 1 ) [ if (o. rl. r2. ml ) 3 , 

erandK  12)[if(o.rl.r2.ml)3, 

erand2( 13)[if(o.rl.r2.ml)3, 

x tmemaddr ( 14) Cm] 

i  f ( exq_i  f  _act i  vated[q3  , 

(11)  [rl3,avai l_operand2( 12) [r23 ) 

_if_fetch[q3  ,  req_f etchr (  15) [ rl  .  q  3 

tchr( 17) [rl.q3 ; 

i  f ( exq_i  f_fetch[q3,  avail_fetchr(15)[vl3, 

f etchr ( 17) [v23 ,  avai 1 _operator ( 1 1 ) [ o 3 )  => 

_app 1 y [ q3 ,  req_app ly_rop( 16) [ o.  vl .  v23 ; 

f (exq_i  f _app ly[q3,avail _nex tmemaddr ( 14) [m2  3 

operand3( 13) [m33 ,avai l_apply_rop( 16) [v33,  => 

_cond [ q  3 ,  req_cond (17)[v3.m3.m23; 

_i f ( exq_i f _cond [ q 3 ,  avai 1 _cond ( 1 7) [ m3 3 )  => 

exq (  1  )  [m3. q  3  ; 
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